まず、「〇〇 な場合に命令の処理が詰まって遅くなります」といった説明の後に、「では、具体的にこういったケースを考えてみましょう」という具体例を持ってくる展開が多く、とても親切だと感じました.また、このような具体例の説明のときにほぼ必ず図が用いられています.特に全体を通して頻繁に出てくる命令流の図は非常に分かりやすかったです.また、コード例とそれを用いた実験も豊富でした.具体的には、キャシュの章では実際にキャッシュミスを意図的に起こすコード・キャッシュヒットを意図的に起こすコードをそれぞれ実行してどれくらい速くなったか、などを確認できます.実際に理解した CPU の機構により速度が変わることを体感できたことで、理解度が深まった気がします.
構成に一貫性がある
この辺りも個人的にはかなり良かったです.特に各章は、
CPU における高速化のための仕組み
その仕組みがうまく機能しないケース・むしろ速度に悪影響を与えるケース
ハードウェア・ソフトウェアによる緩和策
まとめ
という構成でほぼ一貫しており、非常に読みやすかったです.
難易度が丁度良い
より専門的な書籍や論文を読む足がかりになる
難易度もかなり丁度良く、普段 CPU を意識しない Web 寄りのソフトウェアエンジニア 〜 低レイヤ寄りのソフトウェアエンジニアあたりまでの人は読むとかなり学びがあるのではないでしょうか?自作 OS をしている人は 6 章 〜 8 章あたりの内容(仮想記憶、I/O、システムコール、例外、割り込み)は既に知っている内容も多いと思いますが、これらの仕組みを CPU の処理速度への影響という観点からまとめあげているため、依然として多くの学びがあると思います.例えば「TLB ミスと割り込みや例外による CPU の速度低下ってどっちの方が深刻なんだろう?」とか「パイプライン化などの高速化の機構により得られる恩恵と無駄な I/O を減らすことにより得られる恩恵ってどっちが大きいんだろう?」などの疑問に対する自分なりの答えが見つかるようなイメージです.自作 OS などは基本的には速度面を気にして設計・実装まですることはないと思うので、このような観点から知っている内容を復習できた点も個人的には嬉しかったです.
ソフトウェアを高速化するための具体的な技法みたいな部分にはあまり期待しない方が良いかもしれない。当たり前ですが、CPU 側の高速化技術に焦点を当てた書籍だからです。書籍内で紹介されている CPU レベルでの高速化技法は、ソフトウェア実装側からは操作できなかったり、意図的に使えたとしても高速化を達成するのが相当に難しかったりするからです。ただ、各章には「ソフトウェアによる緩和」という節が設けられており、一応こんなこともできるよ、というのは書かれています。
TEE はハードウェアレベルで安全な隔離実行環境です.ハードウェアレベル、というのは root of trust がハードウェアであることを意味しており、 TEE は CPU が root of trust になります.昨今では様々なデータを扱うプログラム(プロセス)が存在しますが、それらを強力な権限を持つ攻撃者から守る手段が乏しく、より改竄されにくいハードウェアがプロセスに強力な保護を提供しようというものです.技術的には、MMU / TLB などのアドレス変換周りの技術を用いた特別なアドレス空間の作成 とメモリ暗号化技術により、通常のプロセスや特権的なソフトウェア(e.g. OS、ハイパーバイザー) からの攻撃にも耐性を持つ環境でプロセスを実行できます.Intel Software Guard Extension (SGX) は Intel 製の CPU における TEE であり、ring 3 のプロセスを安全に実行できるものです.SGX の概要は aos さんの記事 が詳しいです.TEE はチップベンダごとに Arm TrustZone や RISC-V KeyStone 、AMD SEV-SNP 等が存在しますが、今回は割愛します.TEEはいわゆる秘密計算技術のうちの一つですが、完全準同型暗号や秘密分散を用いた手法よりもオーバーヘッドが小さく、より実用的であるという特徴があります.近年では、機密データを扱うソフトウェアとして誰もが納得するであろう Database Management System (DBMS) を TEE を用いて保護する研究が増えています.従来のリレーショナルな RDBMS をはじめ、KVS を TEE で保護する研究もあります.今回紹介する論文は古典的な RDBMS におけるストレージエンジン(明確な定義はともかく、メモリ及びストレージ上のデータ操作を行う DBMS の心臓のようなもの) を TEE を用いて保護する研究になります.
この研究のモチベーションは?
以下、論文からの引用です.
Though some enclave-based encrypted databases emerge recently, there remains a large unexplored area in between about how confdentiality can be achieved in diferent ways and what infuences are implied by them.
以降の説明に備え、Enclage が想定する基本的なストレージエンジンの構造を説明します.Enclage は B+ tree ベースのインデックスとヒープファイルベースのデータストア(データのキャッシュ)を持つストレージエンジンを想定しています.後者はいわゆる Buffer Pool というやつです.ストレージエンジンはデータへのアクセスが発生すると、インデックスが貼られている場合はまずインデックスを探し、無ければ Buffer Pool にアクセスします.それでもなければストレージから Buffer Pool にデータを読み込みます.イメージは以下の画像のようになります.Buffer Pool について詳しく書かれた資料はあまり無い気がしますが、The internals of PostgreSQL は詳しめに書かれています.
です.まず好きなのは間違いなくインフラです.セキュリティは研究をする上では楽しいですが、CTF やセキュリティの業務(レッド・ブルー共に)はあまり興味が出ませんでした.次に得意かどうかですが、これもどちらかというとインフラの方が得意かなと思っています.インフラはいろいろな技術(アプリケーション・ネットワーク・ストレージ)を横断的に理解し、適切に組み合わせる、みたいなことが必要なのかな(?)と思ってますが、セキュリティに関してはむしろ、特定の技術に対する深度が大事な気がします.まあこれは完全に偏見なので、なんとなくです.最後に将来性があるかどうかですが、これはややセキュリティに軍配が上がるかなと思っています.LLM を始めとする AI 技術の発展に加えて、クラウドにおけるフルマネージド化の流れを見ていると、「本当に何十人もの人間が常に気をつけてインフラを設計・改善をしないといけないほどアプリケーションの複雑化は止まらないのか?」みたいな疑問があり、どこかでインフラ技術の発展がほとんどのアプリケーションが必要とする非機能要件を今よりもはるかに容易に満たせる世界が来てしまうのでは?と思っています.一方で、セキュリティは常にシステムが存在する限り需要は増え続ける分野な気がしています.また、自動化も心理的にしづらい気もします.
4 は研究室内の議論(= 後輩の研究をチクチクする)で培われたと思います.指導教員や博士の先輩のような優秀な人を見ていると、自分の意見だけでなく他人の意見に対して非常に(時には本人よりも)解像度高く分析し、的確なコメントを行なっていました.こうした能力は分野に限定されるものではないため、自分としては特に身につけたい能力の一つでした.今でも身についているとは口が避けても言えないですが、センス or 議論の繰り返しの中でしか身につかない能力であり、少しずつ向上していると最近は感じています.仕事では期間・お金などの理由により妥協点を探すことになると勝手に考えているのですが、大学院は「膨大な時間の中で特定の問題を突き詰められる」場所なので、このような時間効率を無視した議論により培われる類の能力は卒業するまでに磨きをかけておきたいです.
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.
If the pair is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
もしそのペアが存在しない場合はアドレス変換テーブルに新しいエントリとして登録します。
If Merge_flag is false, add the triplet to
the translation table.
2番目は上述の通りKVMAPIの仕様と内部実装を探索する根気があればいけると思います。どちらかと言うと、KVM自体 or デバイスエミュレーションの実装に興味がある人がやると良いかもしれないです。また、1番目に比べればはるかに簡単にVMを起動可能 + 命令の実行の正確性をKVMが保証してくれるため、ただゲストOSを動かすだけでなくVMM側の機能実装を頑張りたい人はこっちの方が合っていると思います。
3番目は正直どんな実装になるのか分かりませんが、コンテナランタイムを読めるようになりたい or コンテナ技術そのものに興味があるという人は合っているかもしれません。自作VMMというより自作コンテナランタイムみたいな感じになるので、1,2番目よりは楽しさや目的も結構違ってくるのかなと思います。(僕は普通にどっちも興味があるので、今後自作コンテナランタイムやってみたいと思っています)