投機的実行パッチは何から私を守りますか？

Question

AMD、ARM、IntelのCPUのさまざまな脆弱性に対する最近公開された投機的実行攻撃のアプリケーションレベルとOSレベルの両方で、パッチの弾幕が出ています。

私は攻撃を完全に理解しておらず、それらの完全な内訳を求めていません。私が知りたいのは、出てくるパッチの各カテゴリが私を購入するものです。

たとえば、私がWindows OSを使用していて、FirefoxとChromeを実行していて、OSにパッチが適用されているが、どのブラウザーにもパッチが適用されていない場合、何が原因ですか？ その場合でも、JavaScriptを介してカーネルメモリを読み取る投機的実行は可能ですか？

ブラウザベクトルとOS以外に、エンドユーザーにとって他に明らかなリスクはありますか？他のさまざまなソフトウェアへのパッチの適用については読んだことがありますが、他の（ブラウザ以外の）ソフトウェアがここで本当に重要である理由がわかりません。

おまけとして、私はMozillaとMicrosoftがJavaScriptのタイミングメカニズムの一部を意図的に不正確/不正確にすることにより、ブラウザーを介した攻撃を一時的に軽減したことを読みました。あなた自身の時間測定ライブラリをバンドルしてそれをバイパスすることは理論的に可能ではないでしょうか？

diagprov · Accepted Answer

噛みます...

まず、メルトダウンを処理しましょう（Google：P3）。ご存知のとおり、システムには、Intel/x86でリング0（スーパーバイザーコード）およびリング3（ユーザーモード）として知られるコードに対する複数の特権レベルがあります。これらは、セグメントセレクターのCPLビットフィールドの選択肢です。コードは、1つのセグメントセレクターまたは別のセグメントセレクター（アドレススペース全体をカバーするセレクター）を使用して実行されており、これにより、コードを実行できる特権が決まります。

並行して、CR3レジスタのページテーブルによって制御される仮想メモリがあります。ページングにより、実際のバッキングストレージ（物理メモリ）の量に関係なく、特定のサイズの仮想アドレス空間が可能になり、オペレーティングシステム開発者は、タスクがメモリを使用しているときにページをスワップ（ウィンドウ：ページファイル）に書き込むなどの操作を実行できます。しばらくアクセスしておらず、物理的なRAMが必要です。ページテーブルにもユーザービットがあり、cpl 3で実行されているコードでコードを表示できるかどうかを制御します。ビットが設定すると、ユーザーモードコードはページを表示できます。

ここで、理解すべき2つの重要なポイントがあります。まず、x86（および他の多くのアーキテクチャ）では、ハードウェアレベルのタスクは存在しません。プロセス（Linuxタスク、Windowsプロセス）は、完全にソフトウェアの概念です。これは、各プロセスに独自の仮想アドレス空間を割り当て、プロセスが切り替わると、関連するページが切り替わり、新しいプロセスを仮想アドレス空間に「プラグイン」し、古いプロセスを削除します（または物理的に削除されていなくても、マッピングを解除します）。 RAM）一時的に。

2番目に理解する必要があるのは、これは比較的高価なプロセスであるため、オペレーティングシステムの設計者は「上位半分のカーネル」を考案したことです。各プロセスのアドレス空間では、カーネルはメモリの上位半分に完全にマップされます。これは私たちに重要な利点をもたらします：カーネルが割り込みを処理する必要がある場合、またはIOを実行する必要がある場合、システムコールまたは割り込みハンドラーを介してカーネルスペースにジャンプでき、プロセスのアドレススペースを切り替える必要はありません。タスクが他の理由でアドレススペースの切り替えを必要としない場合（これはコンテキスト切り替えとは少し異なります。これはレジスター状態の保存であり、場合によっては上位半分の設計の使用を回避できます）。素晴らしく効率的：カーネルはその作業を行い、ユーザーモードにできるだけ早く戻ります。

残念ながら、Intel CPUの特権レベル全体で投機的実行が発生することが判明しました。特に、CPL 3として実行されているコードは、ユーザービットがクリアされたページを投機的にロードできることがわかります（スーパーバイザ/リング0-2のみ）。メルトダウンは、投機的にのみ実行される命令を通じてページごとに上半分からメモリを参照することにより、これを利用します。ただし、プロセッサはそれらのページを上位のキャッシュにプルし、キャッシュベースのタイミングサイドチャネルになります。

MacOSおよびWindowsのKPTIおよび同等のパッチは、上位半分のデザインを使用しないことでこれを防ぎます。カーネルアドレススペースに入るのに必要な最小限のものだけがすべてのプロセスにマッピングされます。カーネルの残りの部分は、別個のプロセスのように独自の仮想アドレス空間にあります。これには2つの主な効果があります。

カーネルへのエントリは、アドレス空間の切り替えを意味します。これは、上位半分の設計よりもコストがかかるため、5〜30％の速度低下の見積もりです。「ワークロードに依存します」という説明の理由は、カーネルに入る必要がある回数に依存するためです。
ただし、現在、プロセスと同じ仮想アドレス空間に残されているカーネル空間はごくわずかであり、そのほとんどは興味のない割り込みハンドラです。あなたはそれを漏らすことができますが、それはより小さなターゲットであり、その場所もランダム化することができます。ディスク暗号化キーなどは別の仮想アドレス空間に存在するため、最初にカーネルプロセスに切り替える必要があるため、ディスク暗号化キーなどへの有効な参照はもはや存在しません。

これは明らかに悪いニュースです。同じ問題が一部の種類のハイパーバイザー設計で発生する可能性があります。コンテナーは完全にカーネル構造であるため、プロセスと同様に影響を受けます。

Spectre（Google：P1、P2）も同様に機能しますが、攻撃者がターゲットにアドレス空間で何らかの投機的実行を実行させ、サイドチャネルを介してそれをリークさせることができます。 Spectreの論文との重要な違いは次のとおりです。

スペクター攻撃は、投機的に実行された命令が、犠牲ページのプロセスがページフォールトや例外をトリガーすることなく通常アクセスできるメモリから読み取ることができることを前提としています。たとえば、プロセッサがユーザープロセスの命令の投機的実行によってカーネルメモリにアクセスできない場合でも、攻撃は機能します。 [12]。結果として、スペクターはメルトダウンに直交します[27]

つまり、Spectreを使用して、特権のないプロセスからカーネルメモリを直接読み取ることはできません。また、より高い特権レベルのメモリを読み取ることもできません。

これらの問題を修正するために、いくつかの可能な解決策があります：

XEN XSA-254のFAQ は、Intel、AMDなどが、ハイパーバイザーへのエントリ時に分岐予測ロジックをフラッシュするマイクロコードの更新を準備し、この境界を越えてポイズニングの試みが確実に削除されることを示唆しています。
投機的実行が発生しないように、コードに間接ジャンプを適用することについても言及しています（これは他の場所にも当てはまります）。この防御策は、CPUのオプティマイザを効果的に無効にすることであり、問題のソフトウェアを再コンパイルする必要があります。他の回答で述べられているように、GCC、Clangに追加されているのはこの防御です。

今、あなたが尋ねた実際の質問に答えるために：

たとえば、FirefoxとChromeを実行しているWindows OSを使用していて、OSにパッチが適用されているが、どのブラウザーにもパッチが適用されていない場合、何が原因ですか？その場合でも、JavaScriptを介してカーネルメモリを読み取る投機的実行は可能ですか？

KPTIパッチシリーズまたは同等のものをお持ちの場合、答えは「いいえ」です。より正確には、できますが、アドレススペースを切り替えるカーネルコードなど、興味のないものしか見つかりません。

おまけとして、私はMozillaとMicrosoftがJavaScriptのタイミングメカニズムの一部を意図的に不正確/不正確にすることで、ブラウザーを介した攻撃を一時的に軽減したことを読みました。あなた自身の時間測定ライブラリをバンドルしてそれをバイパスすることは理論的に可能ではありませんか？

理論的には、ブラウザで必要な程度まで正確な測定方法がすでに存在している場合は、そうです。ただし、独自の測定値をバンドルするには、ブラウザを拡張する必要があります。ブラウザのJavaScriptが完全にブラウザ提供のAPIを使用しているので、JavaScriptをロードするほど簡単ではありません。したがって、理論的には、クローズされていない測定を可能にするコードパスがある場合は、はい、それ以外の場合は、いいえ。

結果として、私はすべての実用的な目的のためにノーで行くでしょう。

概要：

KPTIシリーズのパッチは、Intel CPU上のMeltdown、つまり完全なカーネルアドレス空間の読み取りから明示的に保護します。
スペクターは同じ投機的実行を可能にするため、保護するのがより困難ですが、アドレス空間全体で異なる犠牲プロセスをターゲットにします。 KPTIはそれを修正しません。個々のソフトウェアパッケージは緩和策を展開する必要があります。対照的に、Spectreはリング3とリング0の特権の境界を超えることはできません（ただし、リング0-リング0（または "-1"ハイパーバイザー）を越えて、Xenのコメントを超えられると思います。

Steffen Winkler · Answer

たとえば、FirefoxとChromeを実行しているWindows OSを使用していて、OSにパッチが適用されているが、どのブラウザーにもパッチが適用されていない場合、何が原因ですか？ その場合でも、JavaScriptを介してカーネルメモリを読み取る投機的実行は可能ですか？

はい。私は推測する。あなたが説明した場合、あなたはまだ Spectre に対して脆弱ですが、（おそらく？） Meltdown に対して脆弱ではありません。 Spectreが誰かにカーネルメモリの読み取りを許可しているかどうかはわかりません。ただし、別のユーザープロセスに割り当てられたメモリを読み取ることは間違いなく可能です。

Spectreのパッチ/修正が利用可能になるまでにはしばらく時間がかかります。あなたはそれについてもっと読むことができますここ。

要点は、私が収集したものから、Spectreに対する保護は、少なくとも現時点ではプロセス/アプリケーションレベルで発生する必要があるということです。 Google 、 [〜＃〜] llvm [〜＃〜] および [〜＃〜] gcc [〜＃〜] 開発者はすでに作業していますこの正面に。

Spectreホワイトペーパーによると、まだ調査が必要であり、マイクロコードを更新することでSpectreから保護することさえ可能であることに注意してください。出典：13ページ、スペクター白書「7つの対策」。

その間：

Google によると、Chromeには1月23日に完全な修正が展開されるまでこの問題に対処する機能があります。

編集する

私がSpectreについて言及している理由は、質問の中で「JavaScript」が言及されているということです。私が知っているのは、SpectreホワイトペーパーのJavaScriptスニペットだけです。そのため、質問をしている人は、2つのセキュリティ上の問題があり、どちらも問題があることに気づいていません。

編集2

見たことはあるが前に読んだことがないソースを見つけました。これにより、さらに情報が追加されます。

https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html 。

編集3

Firefoxはバージョン57.0.4にパッチされました。このパッチには、質問の「ボーナス」の部分で言及されているJavaScript時間関数の精度の低下が含まれています。

M&#39;vy · Answer

問題はチップ自体にあります。効率的な並列化を可能にするために、プロセッサは、起こりそうなことを想定して、命令を順不同で実行できるようにします。これは、予測が正しいたびに時間を大幅に増やすことができます。

これを完全に修正することは、特にソフトウェアで修正できないように見えるSpectreの場合に、ハードウェアまたはマイクロコード、あるいはその両方を更新することを意味します。

ソフトウェアパッチ（KPTI/KAISER）は、ユーザースペースにマッピングされるカーネルスペースの量を制限することによって、問題をある程度（メルトダウンのみ）緩和することができます。このパッチは、カーネルアドレススペースレイアウトのランダム化（KASLR）に対するサイドチャネル攻撃を回避するために設計されたものであり、ある程度までのメルトダウンから誤って保護します。 x86アーキテクチャの要件のため、完全ではありません。

これはハードウェアの問題であるため、通常、ユーザー空間プログラムを修正する必要はありません。これらのユーザー空間プログラムはカーネルコードによって実装されたシステムコールに依存しているため軽減が可能です。これにより、チップに送信されるものを少し制御できますが、ハードウェアが機能するために必要なものに制限されます。