はじめに

intel CPUにおいて、投棄実行のメカニズムにまつわる脆弱性がまた見つかったそうなので解説を試みようと思います。

なお、この脆弱性の名前は複数あります。
発見者は Foreshadow と呼び、intelは L1 Terminal Fault (略称 L1TF) と呼んでいます。

L1TF

まずSMT(Hyper threading)対応のコアを持つ必要があります。
このコア上で2つのプロセス、またはVMが動いています。一つをvictim、他方をattackerのプロセスが動いている状態とします。

victimのプロセッサが重要な情報をメモリにread/writeし、その情報がL1 Data Cacheに乗っています。

intel CPUのキャッシュ構成は、コアにL1とL2のキャッシュが存在し、すべてのコアで共有するL3キャッシュがあるという構成です。なおL1キャッシュは命令とデータ用に分割されたキャッシュを持つハーバード・アーキテクチャであり、L2とL3は命令とデータ混在のユニファイドキャッシュです。

attackerはvictimのメモリの内容を読もうとL1 Data Cacheにアクセスしますが、メモリ保護機構により当然読むことはできません。
ですが、attackerがpageにマッピングされていない領域を読もうと page fault を起こすと、page faultが処理される間の短時間、メモリ保護機構が無効になってしまい、その間投棄実行によりL1 Data cacheの内容が読めてしまうようです。victimがread/writeしているキャッシュライン含め。。

(メモリ保護機構が無効になるというのは、page faultを起こした後、投機実行している部分はなんとPTEのpresentフラグ(pageが物理メモリ上に存在するかどうかを表すフラグ)などをことごとく無視して実行してしまい、よって自分のpageではなくても関係なくなり、つまりメモリ保護機構が無効になり、L1 Data cacheにあるデータを読めてしまうようです。どうせ投機実行だから状態が元に戻ればいいという速度優先の設計思想なんでしょうね。)

あとはSpectre Variant 1の手法でFLUSH+RELOADで読みたいデータの痕跡をキャッシュに残します。これで投棄実行の結果がキャンセルされてもデータの痕跡はキャッシュに残るので、サイドチャネル攻撃により値の復元ができます。と。。

投機実行の仕組みを想像する

メモリ保護が無効になるところを解説しましたが、これで投機実行の仕組みがだいたい想像できました。
CPU内部でのμ-opの実行は2つに別れます。一つは投機実行、もう一つは「状態チェック」とでも名付けます。

投機実行はとにかく速度最優先。必要最低限の情報が揃えばとにかく処理を進めます。足りない分は推測で補ったりします(分岐予測みたいに)。OSの状態とかおかまいなしです。
「状態チェック」は正確性最優先。投機実行の入力や処理中の状態をチェック。おかしなところがなくOKなら投機実行の結果を確定、NGなら投機実行をストップし、確定したところまで状態を巻き戻し、やり直します。

投機実行は先を行きどこどこ処理をしていき、「状態チェック」が後からよちよち続き、後片付けをしていくイメージでしょうか。

こう考えればL1TFもMeltdownも理解できる気がします。投機実行はOSの状態やメモリ保護などおかまいなしにどんどん先行する。先行する間に読めてはいけないメモリが読めてしまう。「状態チェック」はあとからついてきて、「あっ、こいつメモリ保護違反起こしやがった。投機実行中止！状態よ戻れ！一般保護違反例外投げろ！」とするわけです。投機実行が完了する前にキャッシュに痕跡を残せばいいわけです。。

あくまで想像の設計ですが、もし正しいなら、直し方がわかります。投機実行を今ほどアグレッシブにせず、実行前に必要最低限の状態チェックを行うようにマイクロコードを書き換えれば良さそうです。