9月 14, 2021

Meltdown and Spectre,explained

最近、私は主にアプリケーションレベルのネットワーキングと分散システムで知られていますが、私はキャリアの最初の部分をオペレーテ 私は、現代のプロセッサとシステムソフトウェアがどのように機能するかの低レベルの詳細に深い魅力を維持しています。 最近のMeltdownとSpectreの脆弱性が発表されたとき、私は入手可能な情報を掘り起こし、より多くを学びたいと熱望していました。

この脆弱性は驚異的です; 私は彼らが最後の10-20年のコンピュータサイエンスの中で最も重要な発見の一つであると主張するでしょう。 緩和策も理解するのが難しく、それらに関する正確な情報を見つけるのは難しいです。 これは、彼らの批判的な性質を考えると驚くべきことではありません。 この脆弱性を緩和するには、主要なCPU、オペレーティングシステム、およびクラウドベンダーのすべてによる秘密の作業が数ヶ月必要でした。 文字通り何百人もの人々がそれらに取り組んでいたときに問題が6ヶ月間ラップの下に保たれたという事実は驚くべきことです。MeltdownとSpectreの発表以来、MeltdownとSpectreについて多くのことが書かれていますが、私は脆弱性と緩和策の中間レベルの良い紹介を見たことがありませんでした。 この記事では、脆弱性を理解するために必要なハードウェアとソフトウェアの背景、脆弱性自体の議論、および現在の緩和策の議論を穏やかに紹介す重要な注意：私は軽減策に直接取り組んでおらず、Intel、Microsoft、Google、Amazon、Red Hatなどでは動作しないためです。 私が提供しようとしている詳細のいくつかは完全に正確ではないかもしれません。 私は、これらのシステムがどのように機能するか、公開されているドキュメント、およびlkmlとxen-develに投稿されたパッチ/議論の知識に基づいて、この投稿を 私はこの記事のいずれかが不正確であれば修正したいと思いますが、この主題のどれがまだNDAによってカバーされているかを考えると、すぐにそれがこのセクションでは、脆弱性を理解するために必要ないくつかの背景を提供します。

このセクションでは、詳細を大量に光沢し、コンピュータのハードウェアとシステムソフトウェアの限られた理解を持つ読者を対象としています。

仮想メモリ

仮想メモリは、1970年代以来、すべてのオペレーティングシステムで使用される技術であり、ほとんどのソフトウェアが見ているメ). 高いレベルでは、アプリケーションはマシンが実際に持っているよりも多くのメモリを利用することができます。Div>

図1：仮想メモリ
図1：仮想メモリ

図1は、400バイトのメモリが100バイトの”ページ”にレイアウトされた単純なコンピュータを示しています(実際のコンピュータは2の累乗、通常は4096を使用します)。 コンピュータには2つのプロセスがあり、それぞれ200バイトのメモリが2ページにわたってあります。 プロセスは、0-199バイトの範囲の固定アドレスを使用して同じコードを実行している可能性がありますが、互いに影響を与えないように個別の物理メ 現代のオペレーティングシステムやコンピュータは、この例で提示されているものよりも実質的に複雑な方法で仮想メモリを使用しますが、上記の基本 オペレーティングシステムは、アプリケーションが参照するアドレスを、それらをバックする物理リソースから抽象化しています。

仮想アドレスから物理アドレスへの変換は、現代のコンピュータでは一般的な操作であり、OSがすべての場合に関与しなければならない場合、コンピ 最近のCPUハードウェアは、最近使用されたマッピングをキャッシュするTranslation Lookaside Buffer(TLB)と呼ばれるデバイスを提供します。 これにより、Cpuはほとんどの場合、ハードウェアで直接アドレス変換を実行できます。div>

: 仮想メモリ変換

図2は、アドレス変換フローを示しています。

  1. プログラムは仮想アドレスをフェッチします。
  2. CPUはTLBを使用してそれを変換しようとします。 アドレスが見つかった場合は、変換が使用されます。
  3. アドレスが見つからない場合、CPUは一連の”ページテーブル”を参照してマッピングを決定します。 ページテーブルは、ハードウェアが見つけることができる場所（例えば、x86ハードウェア上のCR3レジスタ）にオペレーティングシステムによって提供される ページテーブルは、仮想アドレスを物理アドレスにマップし、権限などのメタデータも含みます。
  4. ページテーブルにマッピングが含まれている場合は、それが返され、TLBにキャッシュされ、ルックアップに使用されます。 ページテーブルにマッピングが含まれていない場合は、OSに「ページフォールト」が発生します。 ページフォルトは、マッピングが欠落または無効な場合にOSが制御を行い、何をすべきかを決定することを可能にする特別な種類の割り込みです。 たとえば、OSがプログラムを終了する可能性があります。 また、いくつかの物理メモリを割り当ててプロセスにマップすることもできます。 ページフォールトハンドラーが実行を継続すると、新しいマッピングがTLBによって使用されます。

図3:ユーザー/カーネル仮想メモリマッピング
図3:ユーザー/カーネル仮想メモリマッピング

図3は、最新のコンピュータで仮想メモリがどのように見えるかを少し現実的に示しています（メルトダウン前-以下の詳細）。 この設定では、次の機能があります。

  • カーネルメモリは赤で表示されます。 これは、物理アドレス範囲0-99に含まれています。 カーネルメモリは、オペレーティングシステムのみがアクセスできる特別なメモリです。 ユーザープログラムはそれにアクセスできないはずです。
  • ユーザーメモリは灰色で表示されます。
  • 未割り当ての物理メモリは青で表示されます。

この例では、仮想メモリの便利な機能のいくつかを見始めます。 主に：

  • 各プロセスのユーザーメモリは仮想範囲0-99ですが、異なる物理メモリによってサポートされています。
  • 各プロセスのカーネルメモリは100-199の仮想範囲にありますが、同じ物理メモリに裏打ちされています。

前のセクションで簡単に述べたように、各ページにはアクセス許可ビットが関連付けられています。 カーネルメモリは各ユーザープロセスにマップされていますが、プロセスがユーザーモードで実行されているときは、カーネルメモリにアクセスできません。 プロセスがそうしようとすると、ページフォルトがトリガされ、オペレーティングシステムがそれを終了する時点でページフォルトがトリガされます。 ただし、プロセスがカーネルモードで実行されている場合(システムコール中など)、プロセッサはアクセスを許可します。

この時点で、このタイプのデュアルマッピング（カーネルを直接マップした各プロセス）は、パフォーマンス上の理由から三十年以上にわたってオペレーテ

CPUキャッシュトポロジ

図4:CPUスレッド、コア、パッケージ、およびキャッシュトポロジ。

脆弱性を理解するために必要な背景情報の次の部分は、最新のプロセッサのCPUとキャッシュトポロジです。 図4は、最新のほとんどのCpuに共通する一般的なトポロジを示しています。 これは、次のコンポーネントで構成されています。

  • 実行の基本単位は、”CPUスレッド”または”ハードウェアスレッド”または”ハイパースレッド”です。”各CPUスレッドには、一連のレジスタと、ソフトウェアスレッドのようにマシンコードのストリームを実行する機能が含まれています。
  • CPUスレッドは”CPUコア”内に含まれています。”最新のCpuのほとんどは、コアごとに二つのスレッドが含まれています。
  • 現代のCpuは、一般的に複数のレベルのキャッシュメモリを含んでいます。 CPUスレッドに近いキャッシュレベルは、より小さく、より速く、より高価です。 CPUから離れてメインメモリに近いほど、キャッシュは大きく、遅く、安価です。
  • 典型的な現代のCPU設計は、コアごとにL1/L2キャッシュを使用します。 これは、コア上の各CPUスレッドが同じキャッシュを使用することを意味します。
  • 複数のCPUコアが”CPUパッケージ”に含まれています。”現代のCpuは、パッケージごとに30コア（60スレッド）以上を含む可能性があります。
  • パッケージ内のすべてのCPUコアは、通常、L3キャッシュを共有します。
  • CPUパッケージは”ソケット”に収まります。”ほとんどの民生用コンピュータは単一のソケットですが、多くのデータセンターサーバーは複数のソケットを持っています。

投機的実行

図5:現代のCPU実行エンジン(ソース: Google images)

脆弱性を理解するために必要な背景情報の最後の部分は、”投機的実行”として知られている近代的なCPU技術です。”図5は、最新のCPU内の実行エンジンの一般的な図を示しています。主な問題は、現代のCpuは非常に複雑であり、単に機械命令を順番に実行するだけではないということです。

主な問題は、最新のCpuが非常に複雑で 各CPUスレッドには複雑なパイプラインエンジンがあり、命令を順不同で実行することができます。 この理由は、キャッシュに関係しています。 前のセクションで説明したように、各CPUは複数のレベルのキャッシュを使用します。 各キャッシュミスは、プログラムの実行にかなりの遅延時間を追加します。 これを軽減するために、プロセッサはメモリの負荷を待っている間に前方および順不同で実行することができます。 これは投機的実行として知られています。 次のコードスニペットはこれを示しています。前のスニペットでは、array1_sizearray1のアドレスは使用できます。 CPUはxarray1_sizeより小さいと推測（推測）し、if文の中で計算を実行するかもしれません。 メモリからarray1_sizeが読み込まれると、CPUは正しく推測されているかどうかを判断できます。 それがした場合、それは時間の束を保存し続けることができます。 そうでなければ、投機的な計算を捨ててやり直すことができます。 これは、それが最初の場所で待っていた場合よりも悪いことではありません。

投機的実行の別のタイプは、間接分岐予測として知られています。 これは、仮想ディスパッチのために現代のプログラムでは非常に一般的です。

class Base {
public:
virtual void Foo() = 0;
};class Derived : public Base {
public:
void Foo() override { … }
};Base* obj = new Derived;
obj->Foo();

（前のスニペットのソースはthis postです）

前のスニペットがマシンコードで実装される方法は、objが指すメモリ位置から”v-table”または”virtual dispatch table”をロードしてから呼び出すことです。 この操作は非常に一般的であるため、現代のCpuにはさまざまな内部キャッシュがあり、間接分岐がどこに行き、その時点で実行を継続するかを推測（推測） 繰り返しになりますが、CPUが正しく推測すれば、時間を節約し続けることができます。 そうでなければ、投機的な計算を捨ててやり直すことができます。

メルトダウンの脆弱性

すべての背景情報をカバーしたので、脆弱性に飛び込むことができます。

不正なデータキャッシュロード

Meltdownとして知られている最初の脆弱性は、説明が驚くほど簡単で、悪用するのはほとんど簡単です。 エクスプロイトコードは大まかに次のようになります:

1. uint8_t* probe_array = new uint8_t;
2. // ... Make sure probe_array is not cached
3. uint8_t kernel_memory = *(uint8_t*)(kernel_address);
4. uint64_t final_kernel_memory = kernel_memory * 4096;
5. uint8_t dummy = probe_array;
6. // ... catch page fault
7. // ... determine which of 256 slots in probe_array is cached

上記の各ステップを実行し、それが何をするのか、そしてそれがどのようにユーザープログラムからコンピュータ全体のメモリを読

  1. 最初の行では、”プローブアレイ”が割り当てられます。 これは、カーネルからデータを取得するためのサイドチャネルとして使用されるプロセス内のメモリです。 これがどのように行われるかはすぐに明らかになるでしょう。
  2. 割り当ての後、攻撃者はプローブ配列内のメモリがキャッシュされていないことを確認します。 これを達成するにはさまざまな方法があり、最も簡単な方法には、キャッシュからメモリ位置をクリアするためのCPU固有の命令が含まれます。
  3. その後、攻撃者はカーネルのアドレス空間からバイトを読み取ります。 仮想メモリとページテーブルについての以前の議論から、すべての最新のカーネルは通常、カーネル仮想アドレス空間全体をユーザープロセスにマップするこ オペレーティングシステムは、各ページテーブルエントリにアクセス許可の設定があり、ユーザーモードプログラムがカーネルメモリにアクセ そのようなアクセスは、ページフォールトになります。 それは確かにステップ3で最終的に起こることです。
  4. しかし、現代のプロセッサは投機的な実行も実行し、障害のある命令の前に実行されます。 したがって、ステップ3-5は、障害が発生する前にCPUのパイプラインで実行される可能性があります。 このステップでは、カーネルメモリのバイト(0-255の範囲)にシステムのページサイズ(通常は4096)が乗算されます。
  5. このステップでは、カーネルメモリの乗算されたバイトを使用して、プローブ配列からダミー値に読み取ります。 バイトを4096で乗算することは、”プリフェッチャー”と呼ばれるCPU機能が、必要以上に多くのデータをキャッシュに読み込むことを避けるためです。
  6. このステップにより、CPUは間違いを認識し、ステップ3にロールバックしました。 ただし、推測された命令の結果はまだキャッシュに表示されます。 攻撃者は、オペレーティングシステムの機能を使用して、障害のある命令をトラップし、実行を続行します(たとえば、SIGFAULTの処理)。
  7. 手順7では、攻撃者はカーネルメモリによってインデックス付けされている可能性のあるプローブ配列内の256バイトのそれぞれを読み取るのにかかる時間を反復処理し、確認します。 CPUは場所の1つをキャッシュにロードし、この場所は他のすべての場所（メインメモリから読み取る必要がある）よりも大幅に高速にロードされます。 この位置は、カーネルメモリ内のバイトの値です。

上記の手法を使用し、最新のオペレーティングシステムではすべての物理メモリをカーネル仮想アドレス空間にマップするのが標準的な方法で

今、あなたは疑問に思うかもしれません：”あなたはページテーブルに許可ビットがあると言いました。 ユーザーモードコードがカーネルメモリに推測的にアクセスできるようになったのはどうすればよいですか？”その理由は、これはIntelプロセッサのバグです。 私の意見では、これが可能であるためには、正当な理由、パフォーマンス、またはその他の方法はありません。 すべての仮想メモリアクセスはTLBを介して行われる必要があることを思い出してください。 投機的な実行中に、キャッシュされたマッピングが現在実行中の特権レベルと互換性のある権限を持っていることを確認することは容易に可能 インテルのハードウェアは、単にこれを行いません。 他のプロセッサベンダーは、権限チェックを実行し、投機的実行をブロックします。 したがって、私たちが知る限り、MeltdownはIntelのみの脆弱性です。編集：こことここに示されているように、少なくとも1つのARMプロセッサもメルトダウンの影響を受けやすいようです。

Meltdown mitigations

Meltdownは理解しやすく、悪用するのは簡単で、幸いにも比較的簡単な緩和策もあります（少なくとも概念的には、カーネル開発者は実装が簡単であることに同意しないかもしれません）。

Kernel page table isolation(KPTI)

仮想メモリのセクションでは、最新のオペレーティングシステムはすべて、カーネルメモリをすべてのユーザーモードプロセス仮想メモリ これは、パフォーマンスとシンプルさの両方の理由のためです。 これは、プログラムがシステムコールを行うと、それ以上の作業をせずにカーネルを使用する準備ができていることを意味します。 Meltdownの修正は、このデュアルマッピングを実行しないようにすることです。Div>

図6は、kernel page table isolation(kpti)と呼ばれる手法を示しています。 これは基本的に、ユーザー空間で実行されているときにカーネルメモリをプログラムにマッピングしないことに集約されます。 マッピングが存在しない場合、投機的な実行はもはや不可能であり、すぐに障害が発生します。

オペレーティングシステムのvirtual memory manager(VMM)をより複雑にすることに加えて、ハードウェアの支援がなければ、この手法は、遷移ごとにページテーブルを変更新しいx86Cpuには、ASID（アドレス空間ID）またはPCID（プロセスコンテキストID）として知られる機能があり、このタスクを大幅に安くするために使用できます（ARM PCIDでは、IDをTLBエントリに関連付け、そのIDを持つTLBエントリのみをフラッシュすることができます。 PCIDを使用すると、KPTIは安くなりますが、それでも無料ではありません。

要約すると、Meltdownは非常に深刻で脆弱性を悪用するのは簡単です。 幸いにも、それはすでにすべての主要なOSベンダーによって展開されている比較的簡単な緩和策を持っています,将来のハードウェアが明示的に説明

Spectreの脆弱性

SpectreはMeltdownのいくつかのプロパティを共有し、二つの亜種で構成されています。 Meltdownとは異なり、Spectreは悪用するのが実質的に困難ですが、過去20年間に生産されたほぼすべての最新のプロセッサに影響を与えます。 基本的に、Spectreは、特定のセキュリティ脆弱性に対する最新のCPUおよびオペレーティングシステムの設計に対する攻撃です。

境界チェックバイパス(Spectre variant1)

最初のSpectre variantは”境界チェックバイパス”として知られています。”これは次のコードスニペットで実証されています（これは、上記の投機的実行を導入するために使用したのと同じコードスニペットです）。

if (x < array1_size) {
y = array2 * 256];
}

前の例では、次の一連のイベントを想定しています。

  1. 攻撃者はx。
  2. array1_sizeはキャッシュされていません。
  3. array1はキャッシュされます。
  4. CPUは、xarray1_sizeより小さいと推測します。 （Cpuは、さまざまな独自のアルゴリズムとヒューリスティックを使用して推測するかどうかを決定します。)
  5. CPUは、array1_sizeがロードされるのを待っている間にifステートメントの本体を実行し、Meltdownと同様の方法でキャッシュに影響を与えます。
  6. 攻撃者は、さまざまな方法のいずれかを介してarray1の実際の値を決定することができます。 （キャッシュ推論攻撃の詳細については、研究論文を参照してください。)

Spectreは、この脆弱性が特権の昇格に依存しないため、Meltdownよりも悪用するのがかなり困難です。 攻撃者は、カーネルにコードを実行させ、誤って推測する必要があります。 通常、攻撃者は投機エンジンを毒殺し、それを誤って推測するように欺く必要があります。 そうは言っても、研究者はいくつかの概念実証の悪用を示しています。私はこの悪用が本当に信じられないほどの発見が何であるかを繰り返したいと思います。

私は個人的にこれをMeltdown自体のようなCPU設計上の欠陥とは考えていません。 私はこれを、現代のハードウェアとソフトウェアがどのように連携するかについての基本的な啓示と考えています。 CPUキャッシュを間接的に使用してアクセスパターンを学習できるという事実は、しばらくの間知られていました。 CPUキャッシュがコンピュータのメモリをダンプするサイドチャネルとして使用できるという事実は、概念的にもその意味においても驚異的です。

分岐ターゲットインジェクション（Spectre variant2）

間接分岐は現代のプログラムでは非常に一般的であることを思い出してください。 SpectreのVariant2は間接分岐予測を利用して、cpuを推測的にメモリ位置に実行させ、それ以外の場合は実行されなかったメモリ位置に侵入させます。 これらの命令を実行すると、キャッシュ推論攻撃を使用して検出できるキャッシュ内の状態を残すことができれば、攻撃者はすべてのカーネルメモリをダンプすることができます。 Spectre variant1と同様に、Spectre variant2はMeltdownよりも悪用するのがはるかに困難ですが、研究者はvariant2の概念実証の悪用を実証しています。

Spectre mitigations

Spectre mitigationsは、メルトダウンの緩和よりも実質的に興味深いものです。 実際、学術的なSpectreの論文は、現在、既知の緩和策はないと書いています。 舞台裏で、そして学術研究と並行して、Intel（そしておそらく他のCPUベンダー）と主要なOSとクラウドベンダーは、軽減策を開発するために数ヶ月間猛烈に働いて このセクションでは、開発および展開されたさまざまな緩和策について説明します。 これは、正確な情報を得ることは信じられないほど難しいので、私は様々な情報源から物事をつなぎ合わせているので、私が最もかすんでいるセクシ

Static analysis and fencing(variant1mitigation)

既知のvariant1(bounds check bypass)mitigationは、攻撃者が投機を妨害するように制御される可能性のあるコードシーケンスを決定するためのコードの静的解析 脆弱なコードシーケンスには、lfenceなどのシリアル化命令が挿入され、フェンスまでのすべての命令が実行されるまで投機的実行が停止する可能性が フェンスの指示を挿入するときは、パフォーマンスに深刻な影響を与える可能性があるため、注意が必要です。

Retpoline(variant2mitigation)

最初のSpectre variant2(branch target injection)mitigationはGoogleによって開発され、”retpoline”として知られています。「Googleが単独で開発したのか、GoogleがIntelと共同で開発したのかは不明です。 私はそれがGoogleによって実験的に開発され、Intelハードウェアエンジニアによって検証されたと推測しますが、私は確信していません。 “Retpoline”アプローチの詳細は、このトピックに関するGoogleの論文に記載されています。 私はここでそれらを要約します（私は論文でカバーされているアンダーフローを含むいくつかの詳細について光沢を付けています）。

Retpolineは、関数の呼び出しと戻り、関連するスタック操作がコンピュータプログラムで非常に一般的であるため、Cpuはそれらを実行するために大きく最適化されているという事実に依存しています。 （関数の呼び出しと関数からの戻りに関連してスタックがどのように機能するかに慣れていない場合、この投稿は良い入門書です。)一言で言えば、”呼び出し”が実行されると、戻りアドレスがスタックにプッシュされます。 “ret”はリターンアドレスをポップオフし、実行を続行します。 投機的実行ハードウェアは、プッシュされた戻りアドレスを記憶し、その時点で投機的に実行を継続します。

retpoline構造は、レジスタに格納されているメモリ位置への間接的なジャンプを置き換えますr11:

jmp *%r11

:

call set_up_target; (1)
capture_spec: (4)
pause;
jmp capture_spec;
set_up_target:
mov %r11, (%rsp); (2)
ret; (3)

前のアセンブリコードが一度に一度に何をするのか、それが分岐ターゲットインジェクションを軽減する方法を見てみましょう。

  1. このステップでは、コードはコンパイル時に既知のメモリ位置を呼び出すので、ハードコードされたオフセットであり、間接的ではありません。 これにより、capture_specの戻りアドレスがスタックに配置されます。
  2. 呼び出しからの戻りアドレスは、実際のジャンプターゲットで上書きされます。
  3. 実際のターゲットに対して戻りが実行されます。
  4. cpuが投機的に実行されると、無限ループに戻ります！ メモリの負荷が完了するまで、CPUは先に推測することに注意してください。 この場合、推測は、攻撃者に観察可能な副作用を持たない無限ループに捕捉されるように操作されています。 CPUが最終的にreal returnを実行すると、効果がなかった投機的実行が中止されます。私の意見では、これは本当に独創的な緩和策です。 それを開発したエンジニアへの賞賛。 この緩和策の欠点は、間接ブランチがretpolineブランチに変換されるように、すべてのソフトウェアを再コンパイルする必要があることです。 スタック全体を所有するGoogleなどのクラウドサービスでは、再コンパイルは大したことではありません。 他の人のために、それは非常に大したことや不可能かもしれません。

    IBRS、STIBP、およびIBPB（variant2mitigation）

    retpolineの開発と同時に、Intel（およびAMDはある程度）branch target injection攻撃を軽減するためにハードウェアの変更に猛烈に取り組んでいるようです。 CPUマイクロコードの更新として出荷される三つの新しいハードウェア機能は次のとおりです:

    • 間接分岐制限投機(IBRS)
    • シングルスレッド間接分岐予測子(STIBP)
    • 間接分岐予測子バリア(IBPB)

    新しいマイクロコード機能に関する限定的な情報 上記のドキュメントを読んで、LinuxカーネルとXen hypervisorのパッチを見ることで、これらの新機能が何をするかを大まかにまとめることができました。 私の分析から、各機能は潜在的に次のように使用されます:

    • IBRSはどちらも特権レベル(ユーザーからカーネル)間の分岐予測キャッシュをフラッシュし、兄弟CPUスレッド上の分岐予測を無効にします。 通常、各CPUコアには二つのCPUスレッドがあることを思い出してくださ 現代のCpuでは、分岐予測ハードウェアはスレッド間で共有されているようです。 これは、カーネルコードを入力する前にユーザーモードコードが分岐予測子を毒殺するだけでなく、兄弟CPUスレッドで実行されているコードも毒殺することがで カーネルモードでIBRSを有効にすると、基本的に、ユーザーモードでの以前の実行と兄弟CPUスレッドでの実行が分岐予測に影響を与えないようになります。
    • STIBPは、兄弟CPUスレッドの分岐予測を無効にするIBRSのサブセットのようです。 私が知る限り、この機能の主なユースケースは、同じCPUコア上で2つの異なるユーザーモードプロセス（または仮想マシン）を同時に実行するときに、兄弟CPUスレッ 正直なところ、STIBPを使用する必要があるときは、今私には完全には明らかではありません。
    • IBPBは、同じ特権レベルで実行されているコードの分岐予測キャッシュをフラッシュするように見えます。 これは、前のコードが実行しようとしているコードに干渉しないようにするために、2つのユーザーモードプログラムまたは2つの仮想マシンを切り替える

    この記事の執筆時点で、branch target injectionの脆弱性に対して実装されていると思われる主な緩和策は、retpolineとIBRSの両方であるようです。 おそらく、これは、ユーザーモードプログラムからカーネルを保護したり、仮想マシンゲストからハイパーバイザを保護する最速の方法です。 将来的には、STIBPとIBPBの両方が、互いに干渉するさまざまなユーザーモードプログラムのパラノイアレベルに応じて展開されることを期待しています。

    IBRSのコストは、新しいIntel Skylakeプロセッサが古いプロセッサに比べて比較的安価であるCPUアーキテクチャ間でも非常に大きく異なるように見えます。 Lyftでは、軽減策がロールアウトされたときに、AWS C4インスタンスの特定のシステムコールの重いワークロードで約20％の減速が見られました。 私はAmazonがIBRSを展開し、潜在的にretpolineも展開したと推測するだろうが、私は確信していない。 Googleは彼らのクラウドにretpolineをロールアウトしている可能性がありますように表示されます。

    時間が経つにつれて、プロセッサは最終的にIBRS”always on”モデルに移行することを期待しています。 これが今日行われない唯一の理由は、マイクロコードの更新を介して既にリリースされたマイクロアーキテクチャにこの機能を改造することの明らかなパ

    結論

    研究結果がコンピュータの構築方法と実行方法を根本的に変えることは非常にまれです。 MeltdownとSpectreはちょうどそれをしました。 これらの知見は、設計者がキャッシュサイドチャネルを介したデータ漏洩の可能性の新しい現実を考慮に入れるにつれて、今後7-10年間（次のCPUハードウェ

    その間、MeltdownとSpectreの調査結果と関連する緩和策は、今後数年間、コンピュータユーザーに大きな影響を与えるでしょう。 短期的には、軽減策は、ワークロードと特定のハードウェアに応じて大幅なパフォーマンスへの影響を与える可能性があります。 これにより、一部のインフラストラクチャの運用変更が必要になる可能性があります(たとえば、LYFTでは、IBRSがSkylakeプロセッサで大幅に高速に実行され、新しいNitro hypervisorがSR-IOVおよびAPICvを使用してゲストに割り込みを直接配信し、IO重いワークロードのための多くの仮想マシン出口を削除するという事実により、一部のワークロードをAWS C5インスタンスに積極的に移動しています)。 デスクトップコンピュータのユーザーは、OSとブラウザベンダーが軽減しようとしているJavaScriptを使用した概念実証ブラウザ攻撃のために、免疫もありません。 さらに、脆弱性の複雑さのために、セキュリティ研究者がパッチを適用する必要がある現在の緩和策でカバーされていない新しい悪用を見つけるこ

    私はLyftで働くのが大好きで、マイクロサービスシステムインフラストラクチャの分野でやっている仕事は、今業界で行われている最も影響力のあ 私は、この脆弱性を研究し、軽減するために膨大な数の人々によって過去6ヶ月にわたって行われた英雄的な仕事に非常に嫉妬しています。 私はそれの一部であったことを愛していただろう！

    さらに読む

    • MeltdownとSpectre学術論文：https://spectreattack.com/
    • Google Project Zeroブログ投稿：https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
    • Intel Spectreハードウェア緩和策：https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
    • https://support.google.com/faqs/answer/7625886
    • 既知の情報の良い要約：https://github.com/marcan/speculation-bugs/blob/master/README.md

Author:
Filed Under: Articles

コメントを残す

メールアドレスが公開されることはありません。