web-dev-qa-db-ja.com

CPUキャッシュのサイドチャネル攻撃は、Meltdownの脆弱性の背景にどのように適合しますか？

注：同様の質問があることは知っています。つまり、 これ ですが、その答えは元の論文からの抜粋であり、攻撃を明確にしませんでした。さらに、回答からいくつかの意味のある議論が行われていることがわかります。そのため、重複の提案がさらに表示されるまで、この質問を投稿します。

いくつかの文献では、次のような漠然とした説明を見てきました。

meltdownの脆弱性は、キャッシュをサイドチャネルとして使用して、ステップ2で見つかった情報を漏洩します。攻撃中、キャッシュをサイドチャネルとして使用するには、キャッシュミスとキャッシュヒットのタイミングの違いを使用して収集するため、攻撃者はキャッシュヒットごとに大量のキャッシュミスを生成する必要があります。データ。

攻撃者が知りたいと思っていた機密データがバイトごとにどの程度正確に決定されているかを誰かが説明できますか？ここでは、ページサイズ（4096）がどのように重要な役割を果たしますか？

meltdownside-channel
1
Sajuuk

そのためのXKCDがあります！ 。

ページは、仮想メモリオペレーティングシステムのメモリ管理用のデータの最小単位です。つまり、データがキャッシュに出入りするときは、少なくとも1ページのチャンクで移動されます。

最も単純なケースでは、攻撃者が1バイトのメモリに関心があると仮定します。このバイトがアドレス0にあるとしましょう。攻撃者は256ページの長さの配列を設定します。この配列を「page_array」と呼びましょう。次に、プロセッサをだまして次のことを実行させます-

1. load address 0 into register[X]
2. load the byte at page_array[PAGE_SIZE * register[x]] into register[y].
   // PAGE_SIZE would usually be 4096

次に、CPUはその間違いを認識し、上記のすべてを元に戻します。ただし、その間、page_array [PAGE_SIZE * register [x]]を含むページがフェッチされ、キャッシュに保存されています。つまり、値が1の場合、期待します-

  • page_array [0〜4095]のバイトがキャッシュにある可能性は低いです。
  • page_array [4096から8191]のバイトは、キャッシュにある可能性があります。
  • page_array [8192+]のバイトがキャッシュにある可能性は低いです。

0から255の範囲のiのpage_array [PAGE_SIZE * i]へのアクセスのタイミングをとることにより、最も速くロードされるページはほぼ確実にキャッシュにあります。違いは十分に大きいので、適切なしきい値を選択することで、ヒットとミスをある程度確実に識別できるはずです。

同じプロセスを複数回繰り返し、特別な手順を実行して配列をキャッシュからフラッシュしてからインデックスに登録することにより、悪意のあるアクターは、非常に高い統計的確率で正しい値を持つポイントに到達できます。

1
Hector