スペクターとメルトダウンのパッチがパフォーマンスにどのような影響を与えるのか、そしてその理由は？

業界がメルトダウン攻撃とスペクター攻撃への対応を続ける中、特にオペレーティングシステムとブラウザの開発者は、これらの問題に対する保護策の開発とテストを続けています。同時に、プロセッサの動作を変更するマイクロコードアップデートのリリースも始まって​​います。

これらの攻撃に関するニュースが最初に報じられて以来、その解決にはパフォーマンスへの影響が伴うことは明らかでした。Meltdownは、少なくとも一部のワークロードでは大きな影響を与えると想定されていましたが、Spectreはより複雑であったため、未知数でした。現在では（少なくとも一部のシステムでは）パッチとマイクロコードが利用可能になっており、その影響は明らかになりつつあります。これらの二重攻撃については当然のことながら、状況は複雑です。

まとめると、現代の高性能プロセッサは、いわゆる投機的実行を実行します。コード内の分岐がどの方向に進むかを推測し、それに応じて投機的に計算を行います。推測が正しければパフォーマンスが向上し、推測が外れた場合は投機的に計算された結果が破棄されます。これはプログラムには透過的であるはずですが、この投機によってプロセッサの状態がわずかに変化することが分かっています。これらの小さな変化は測定可能であり、投機的に使用されたデータや命令に関する情報を明らかにすることができます。

Spectre攻撃では、この情報を利用して、例えばブラウザ内の情報（保存されたパスワードやCookieなど）を悪意のあるJavaScriptに漏洩させることが可能です。同じ原理に基づく攻撃であるMeltdownでは、この情報を利用してカーネルメモリ内のデータを漏洩させることが可能です。

Meltdown は、Intel の x86 プロセッサと Apple の ARM プロセッサに適用されます。また、新しい A75 設計に基づいて構築された ARM プロセッサにも適用されます。Meltdown は、オペレーティング システムがメモリを処理する方法を変更することで修正されます。オペレーティング システムは、ページ テーブルと呼ばれる構造を使用して、プロセスまたはカーネル メモリとその基礎となる物理メモリをマッピングします。従来、各プロセスに割り当てられたアクセス可能なメモリは半分に分割されています。プロセスごとのページ テーブルがある下半分はプロセスに属します。上半分はカーネルに属します。このカーネル部分はすべてのプロセス間で共有され、プロセスごとに 1 セットのページ テーブル エントリが使用されます。この設計は効率的 (プロセッサにはページ テーブル エントリ用の特別なキャッシュがある) であり、カーネルとプロセス間の通信が簡単になるので便利です。

Meltdownの修正は、この共有アドレス空間を分割することです。これにより、ユーザープログラムの実行時に、カーネル側は通常のカーネルページテーブルではなく空のページテーブルを持つことになります。これにより、プログラムがカーネルアドレスを投機的に使用することが不可能になります。

Spectreは、過去10年間に販売されたすべての高性能プロセッサに適用されると考えられています。2つのバージョンが実証されています。1つは、攻撃者がプロセッサの分岐予測機構を「訓練」することで、標的プロセスが予測を誤り、攻撃者が選択したコードを投機的に実行するように仕向けるものです（測定可能な副作用を伴う）。もう1つは、プロセッサを騙して配列の境界外への投機的アクセスを行わせます。配列バージョンは単一プロセス内で動作します。分岐予測バージョンでは、ユーザープロセスがカーネルの予測分岐を「操作」したり、ハイパースレッドが兄弟ハイパースレッドを操作したり、ゲストOSがハイパーバイザーを操作したりすることができます。

業界からの反応については、以前にも記事を書いています。Meltdownは現在までに、Windows、Linux、macOS、そして少なくとも一部のBSD系OSでパッチが適用されています。Spectreはより複雑で、リスクのあるアプリケーション（特にブラウザ）は、配列境界亜種から保護するための特定のSpectre緩和技術を組み込むようにアップデートされています。分岐予測型Spectreに対処するには、オペレーティングシステムとプロセッサのアップデートが必要です。分岐予測型Spectreには、オペレーティングシステムとプロセッサの両方のマイクロコードアップデートが必要です。AMDは当初この攻撃の重要性を軽視していましたが、その後、オペレーティングシステムに必要な制御機能を提供するためのマイクロコードアップデートを公開しました。

これらの様々な緩和策はすべて、パフォーマンスコストを伴います。投機的実行はプロセッサによるプログラム実行速度を向上させるために使用され、分岐予測は、使用している特定のプログラムやデータに合わせて投機を適応させるために使用されます。これらの対策はすべて、投機の威力をいくらか弱めます。大きな疑問は、その程度がどの程度になるかということです。

メルトダウン

Meltdown攻撃のニュースがリークされた際、特定の合成ベンチマークに基づいて、パフォーマンスの低下は30%、あるいはそれ以上になる可能性があると推定されました。ほとんどの人にとって、それほど深刻な影響にはならないと思われます。しかし、影響は、使用されているプロセッサの種類と、そのプロセッサで何をするかに大きく依存します。

朗報としては、Skylake、Kaby Lake、Coffee Lakeといった最新のプロセッサを使用している場合、通常のデスクトップワークロードではパフォーマンスの低下はわずかで、せいぜい数パーセント程度です。これはMicrosoftによるWindows 10での結果ですが、Windows 10でも独立したテストが行​​われており、macOSでも同様の結果が得られています。

もちろん、問題点はあります。Microsoftによると、Windows 7と8は一般的にWindows 10よりもパフォーマンスへの影響が大きいとのことです。Windows 10では、フォントの解析など一部の処理がカーネルから通常のプロセスに移行されています。そのため、Meltdown以前から、Windows 10では新しいフォントを読み込むたびにページテーブルスイッチが発生していました。Windows 7と8では、このオーバーヘッドが新たに発生しています。

数パーセントのオーバーヘッドは、標準的なデスクトップワークロード（ブラウザ、ゲーム、生産性アプリケーションなど）を想定しています。これらのワークロードは実際にはカーネルを頻繁に呼び出すことはなく、ほとんどの時間をアプリケーション自体で（あるいはアイドル状態、つまりキーボードを打つユーザーが実際に何かを行うのを待って）過ごします。ディスクやネットワークを多用するタスクでは、オーバーヘッドはさらに大きくなります。これはTechSpotのベンチマークで非常に顕著です。GeekbenchやCinebenchなどの計算集約型のワークロードでは、全く大きな変化は見られません。多くのゲームでも同様です。

しかし、ディスクベンチマークを実行すると、状況は全く異なります。CrystalDiskMarkとATTO Disk Benchmarkはどちらも、ディスクアクティビティが高い状態ではパフォーマンスが著しく低下し、データ転送速度が最大30%も低下します。これは、これらのベンチマークがカーネルへの連続呼び出しを行う以外、実質的に何も行わないためです。

Phoronix は Linux でも同様の結果を発見しました。PostgreSQL データベースの pgbench などの I/O 集約型ベンチマークでは約 12% の低下が見られましたが、ビデオ エンコーディングやソフトウェアのコンパイルなどの計算集約型ワークロードでは違いはごくわずかでした。

ネットワークを集中的に使用するベンチマークでも同様の結果が得られると予想されます。

作業負荷がなぜ重要なのでしょうか?

ページテーブルエントリに使用される特別なキャッシュは、トランスレーション・ルックアサイド・バッファ（TLB）と呼ばれ、仮想アドレスから物理メモリアドレスへのマッピングを格納する、重要かつ限られたリソースです。従来、TLBは、オペレーティングシステムが異なるページテーブルセットに切り替えるたびにフラッシュ（空に）されていました。だからこそ、分割アドレスは非常に有用でした。ユーザープロセスからカーネルへの切り替えは、異なるページテーブルセットに切り替えることなく実行できたのです（各ユーザープロセスの上位半分は共有カーネルページテーブルであるため）。ページテーブルの変更（下位半分をあるプロセスから次のプロセスに切り替えること）が必要なのは、あるユーザープロセスから別のユーザープロセスへの切り替え時のみです。

Meltdown に対するデュアル ページ テーブル ソリューションは切り替え回数を増やすため、あるユーザー プロセスから次のユーザー プロセスに切り替えるときだけでなく、あるユーザー プロセスがカーネルを呼び出すときにも TLB をフラッシュする必要があります。デュアル ページ テーブルが導入される前は、カーネルを呼び出して応答を受け取ったユーザー プロセスは、操作全体で同じページ テーブルを使用できたため、TLB をフラッシュする必要がまったくありませんでした。現在は、カーネルに入る途中で 1 回のページ テーブル スイッチが発生し、出て行く途中でプロセスのページ テーブルに戻る 2 回目のスイッチが発生します。これが、I/O 集約型のワークロードに大きなペナルティが課される理由です。これらのワークロードは、ベンチマーク プロセスからカーネルに、そして再びベンチマーク プロセスに何度も切り替えるため、ラウンドトリップごとに 2 回の TLB フラッシュが発生します。

Epic GamesがMeltdown対策の有効化以降、サーバーのCPU負荷が大幅に増加したと発表したのは、このためです。ゲームサーバーは通常、専用マシン上で唯一の実行プロセスとして動作しますが、大量のネットワークI/Oを実行します。つまり、「TLBをフラッシュする必要がほとんどない」状態から、「1秒間に数千回TLBをフラッシュする必要がある」状態へと変化しているのです。

古いプロセッサの状況はさらに悪いです。仮想化の進歩により、TLB への負担がこれまで以上に大きくなっています。仮想化ではプロセッサがカーネルを切り替える必要があり、TLB のフラッシュが余計に必要になるからです。このオーバーヘッドを減らすために、Intel の Westmere アーキテクチャではプロセス コンテキスト ID (PCID) と呼ばれる機能が導入され、Haswell では関連命令の INVPCID (PCID の無効化) が導入されました。PCID を有効にすると、TLB の使用方法とフラッシュ方法が変わります。まず、TLB は各エントリに、そのエントリを所有するプロセスの PCID をタグ付けします。これにより、PCID が異なる限り、同じ仮想アドレスからの 2 つの異なるマッピングを TLB に格納できます。次に、PCID を有効にすると、ページ テーブルのセットを別のセットに切り替えても TLB がフラッシュされなくなります。各プロセスは適切な PCID を持つ TLB エントリのみを使用できるため、TLB を毎回フラッシュする必要がなくなります。

これは明らかに、特に仮想化においては有用であるように思われます。例えば、各仮想マシンに独自のPCIDを割り当てることで、仮想マシン間の切り替え時にフラッシュ処理を削減できる可能性があります。しかし、主要なオペレーティングシステムはPCIDのサポートを追加しようとはしませんでした。PCIDは扱いにくく複雑だったため、オペレーティングシステム開発者はPCIDを使う価値があると感じていなかったのかもしれません。HaswellはINVPCIDを搭載し、特定のPCIDに属するTLBエントリをプロセッサに明示的に破棄させる命令を提供することでPCIDの使用をいくらか簡素化しましたが、それでも主流のオペレーティングシステムでは全く採用されませんでした。

Meltdownが登場するまではそうでした。Meltdownのデュアルページテーブルは、プロセッサにTLBフラッシュの実行回数を増やし、場合によっては大幅に増加させます。PCIDは、TLBを消去することなく、異なるページテーブルセットへの切り替えを可能にするために特別に設計されています。そしてMeltdownにパッチが必要になったため、WindowsとLinuxの開発者はついにPCIDとINVPCIDを使用する正当な理由を得ました。

そのため、WindowsはハードウェアがINVPCIDをサポートしている場合（つまりHaswell以降）、PCIDを使用します。ハードウェアがINVPCIDをサポートしていない場合、WindowsはPCIDにフォールバックせず、その機能を一切使用しません。Linuxでは、当初PCIDとINVPCIDの両方をサポートするための取り組みが行われましたが、PCIDのみの変更は、その複雑さと扱いにくさから削除されました。

これは大きな違いです。カーネルへの切り替えとカーネルからの切り替えのコストのみをテストする合成ベンチマークでは、パッチを適用していないLinuxシステムは1秒間に約520万回の切り替えを実行できます。デュアルページテーブルを使用すると、この回数は1秒間に220万回にまで削減され、PCIDを使用したデュアルページテーブルを使用すると、300万回まで回復します。

典型的なデスクトップワークロードにおける1%未満のオーバーヘッドは、PCIDおよびINVPCIDをサポートするマシンを使用した場合のものです。これらのサポートがない場合、MicrosoftはWindows 10では「一部のユーザーはシステムパフォーマンスの低下に気付く」と述べており、Windows 7および8では「ほとんどのユーザー」がパフォーマンスの低下に気付くとしています。

スペクター

Spectre の件は、いつものように複雑です。Spectre による攻撃で最も可能性が高く、広く普及している経路は、ブラウザで実行される JavaScript を介した攻撃です。Spectre の配列境界バージョンを利用して、ブラウザに関する情報を JavaScript に漏洩します。漏洩した情報は、パスワードや Cookie など、直接的に価値あるものになる場合もあれば、さらなる悪用につながる場合もあります。例えば、JavaScript がブラウザのプロセスから情報を読み取り、その情報を使って他のブラウザの脆弱性を悪用し、サンドボックスを突破する可能性があります。

重要なのは、このタイプの攻撃はカーネルアップデートでは修正できないということです。リスクのあるアプリケーションは、配列境界のテストを個別に保護する必要があります。配列のサイズと内容がエンドユーザーによって直接制御されていない場合は安全かもしれませんが、潜在的に悪意のあるユーザーコードによって制御されている場合は、Spectreから保護する必要があるでしょう。

AppleのSafariブラウザで使用されているWebKitの開発チームは、その取り組みとその影響について詳細な記事を執筆しています。一般的な解決策は、プロセッサが配列要素にアクセスできるかどうかを推測するのを防ぐことです。IntelとARMが推奨する解決策は、配列のサイズのテストと配列要素へのアクセスの間に「シリアライズ命令」（推測を禁止する少数の命令の1つ）を挿入することです。

命令のシリアル化は遅く、数百サイクルかかる可能性があるため、WebKit の開発者は異なるアプローチを採用しました。この種の Spectre 攻撃は、配列の境界を大きく超えた要素にアクセスしようとします。末尾から 1 ～ 2 バイト離れた要素ではなく、数ギガバイト離れた要素です。そのため、WebKit は配列にアクセスする前に、アクセスする要素のインデックスを、配列のサイズよりも大きい最も近い 2 の累乗に制限します。開発者は、ほとんどのプロセッサがこの種類の操作を推測的に実行しないことを発見しました。これにより、境界チェックを待つことはできますが、シリアル化によって発生する数百サイクルを待つ必要はありません。

WebKitは多層防御策として、特定のデータ構造において難読化されたメモリアドレスの使用を開始しました。これにより、たとえ投機的にこれらのアドレスにアクセスしようとしたとしても、誤ったアドレスにアクセスされ、たとえこれらのアドレスが悪意のあるJavaScriptに漏洩したとしても、そのアドレスは役に立ちません。Microsoftは長年にわたり、この技術を特定の領域で活用し、悪用可能なデータ漏洩を防御してきました。

これらを総合すると、開発者は現在、Speedometer Webベンチマークで目立った変化は見られず、JetStreamスコアの低下は2.5%未満にとどまっていると報告しています。他のブラウザでも同様の影響を受けると予想されます。この攻撃ベクトルは多くの場所で発生し、システム全体にわたって簡単に修正できないため厄介ですが、修正にかかるオーバーヘッドは妥当なものと思われます。

さて悪いニュース

しかし、Spectreの分岐予測バージョンは別の話です。Microsoftは、この特定の問題に対する防御策は「パフォーマンスに影響を与える」と警告しており、Meltdownの修正とは異なり、より広範なタスクに影響が及ぶ可能性があると述べています。

ソフトウェア開発者やオペレーティングシステム開発者向けに、さまざまなツールが利用可能です。プロセッサレベルの変更とソフトウェアレベルの変更があり、複数のソリューションを組み合わせる必要がある場合があります。これらの新機能は、他のプロセッサセキュリティ機能とも相互作用します。

先週から、Intelがこの攻撃に対するプロセッサの動作を変更するマイクロコードアップデートをリリースする予定であることが分かっています。マイクロコードアップデートにより、Intelはプロセッサに分岐予測の処理方法を制御する3つの新機能を導入しました。IBRS（間接分岐制限投機）は、ユーザーモードアプリケーションによって作成された分岐予測エントリからカーネルを保護します。STIBP（シングルスレッド間接分岐予測）は、コア上の1つのハイパースレッドが、コア上の別のスレッドによって作成された分岐予測エントリを使用することを防ぎます。IBPB（間接分岐予測バリア）は、分岐予測をリセットしてその状態をクリアする方法を提供します。

AMDは先週、同社のプロセッサを搭載したシステムではほとんど対策を講じる必要がないと示唆した。しかし、これは必ずしも真実ではなく、同社はそれに応じてマイクロコードのアップデートをリリースすると報じられている。Zenコアを搭載した現行のプロセッサ（Ryzen、Threadripper、Epyc）では、新しいマイクロコードがIPBPとSTIBPに相当する機能を提供している。Bulldozerファミリーを搭載した旧世代のプロセッサでは、マイクロコードによってIBRSとIBPBが追加されている。

ゼンは（再び）逃げる

ZenにIBRSが搭載されていないのはなぜでしょうか？AMDは、Zenの新しい分岐予測器は同様の攻撃に対して脆弱ではないと主張しています。ほとんどの分岐予測器は、分岐ターゲットバッファ（BTB）と呼ばれる独自の特殊なキャッシュを搭載しており、過去の分岐が行われたかどうかを記録するために使用されます。他のチップ（旧型のAMDチップ、Intelチップ、ARMの設計、Appleチップなど）のBTBは、各分岐の正確なアドレスを記録しません。代わりに、プロセッサのキャッシュと同様に、メモリアドレスからBTBのスロットへのマッピングが行われます。例えば、IntelのIvy BridgeチップとHaswellチップは、4,096の分岐に関する情報を格納でき、各分岐アドレスはBTB内の4つの可能な位置のいずれかにマッピングされます。

このマッピングとは、あるアドレスの分岐が別のアドレスの分岐の動作に影響を与える可能性があることを意味します。ただし、その異なるアドレスが同じ4つの可能な位置の集合にマッピングされている必要があります。Spectre攻撃では、攻撃者は被害者の特定の分岐に対応する（ただし完全には一致しない）アドレスを使用してBTBをプライミングします。被害者がその分岐を行うと、攻撃者が設定した予測が使用されます。

しかし、Zenの分岐予測器は少し異なります。AMDによると、この予測器は常に分岐の完全なアドレスを使用するとのことです。複数の分岐アドレスをBTBの1つのエントリに平坦化することはないのです。つまり、分岐予測器は、標的の実際の分岐アドレスを使用することでのみ学習できるということです。これは幸運な結果と言えるでしょう。AMDはZenで異なる種類の分岐予測器に切り替えました（SamsungがExynos ARMプロセッサで採用しているのと同様に、AMDはパーセプトロンと呼ばれるシンプルなニューラルネットワークコンポーネントを使用しています）。そして、この問題から保護された設計を偶然選択したのです。

これらのハードウェア機能と連携して、「retpoline」と呼ばれるソフトウェア技術が考案されました。これは、従来の「ジャンプ」命令や「コール」命令ではなく、ハードウェアの「return」命令を用いて間接分岐を実行します。return命令は分岐予測器を用いて予測されないため、分岐予測器と同様の影響を与えることはありません。その代わりに、return命令を予測するための独立したリターンバッファが存在します。retpolineを使用することで、予測される可能性のある分岐（予測が誤っている可能性もある）を、予測されないリターンに変換することができます。

最新の（Broadwell以降）Intelプロセッサでは、機密性の高い分岐にretpolineを使用することは安定して動作しません。これらのプロセッサは、リターンバッファではなく分岐予測器を実際に使用できるためです。関数Aが関数Bを呼び出し、関数Cが関数Dを呼び出す…といった深いネストから戻る場合、リターンバッファが空になる可能性があります。Broadwell以降のプロセッサはこのような状況でも諦めず、BTBにフォールバックします。つまり、Broadwell以降のプロセッサでは、retpolineコードであっても攻撃者が用意したBTBを使用する可能性があります。Intelは、マイクロコードのアップデートでこの問題に対処すると述べています。あるいは、リターンバッファを「リフィル」する方法もあります。

一般的に、オペレーティングシステムは、仮想マシン間の切り替え時にIBRSを有効にしてIBPBを使用するか、retpolineを使用してすべてを再コンパイルするか（必要に応じてバッファを補充し、Intelが適切なマイクロコードアップデートを提供することを期待する）、どちらかを選択できます。Microsoftは、すべてが再構築されることを前提とできないため、Windowsではハードウェアが許す限りIBRSとIBPBを使用しています。オープンソースプラットフォームは、retpolineの使用を調査し、IBRSおよびIBPBソリューションを開発しています。

これらによるパフォーマンスオーバーヘッドの大まかなパターンは、Meltdownの場合と似ています。カーネルをあまり使用しないアプリケーションでは大きな違いは見られませんが、カーネル関数に大きく依存するアプリケーションでは、オーバーヘッドが大幅に増加します。これらのアプリケーションはTLBを常にフラッシュする必要があるだけでなく、BTBもフラッシュするようになりました。これは大きな問題です。Intelは分岐予測の精度を90%台後半と推定しています。BTBを常に消去すると、予測率は大幅に低下するでしょう。

しかし、IBRSとIBPBのコストは相当な額になる可能性があります。前述のTechSpotベンチマークでは、システムファームウェア（およびマイクロコード）のアップデートの有無の両方の結果を示しています。ファームウェアアップデートによりカーネルのIBRSとIBPBの保護が有効になるため、SpectreとMeltdownの保護、Meltdownの保護のみ、どちらも適用しないという3つの条件で比較できます。

通常のデスクトップアプリケーションではオーバーヘッドはごくわずかで、ゲームでも同様にパフォーマンスに大きな差は見られませんでした。しかし、カーネルにリクエストを何度も送りつけるストレージベンチマークでは、大きな影響が見られ、時には40%にも達しました。

DragonFly BSDの開発者たちは、Spectre保護が自社のオペレーティングシステムで実際に有効かどうか確信が持てないようです。IBRSとIBPB保護によるパフォーマンス低下は、Skylakeシステムでは約24%、Haswellでは最大53%にも上ります。

RedHatの報告によると、MeltdownとSpectreを併用した場合の影響は、I/O負荷に応じて、ごくわずかから19%の範囲です。業界標準のデータベースベンチマークであるTPC-Cやpgbenchなどのデータベースワークロードでは、パフォーマンスが8%から19%低下します。SPECcpuなどのCPU負荷の高いワークロードでは、パフォーマンス低下はわずか2%から5%です。

発展途上の状況

最も悪用されやすい脆弱性である配列境界スペクター（ブラウザベースのJavaScriptを用いて攻撃される）は、オーバーヘッドの軽減策が少ないように見えるのは、おそらく幸運と言えるでしょう。これは、リモートコード実行やその他の脆弱性を必要としない攻撃ベクトルです（私たちは皆、ブラウザ内でJavaScriptをダウンロードして実行することを好んで行っているため）。そのため、この脆弱性の保護は特に重要です。配列境界テストのほとんどは、攻撃者が制御できないため安全です。また、WebKitで使用されるような追加チェックを慎重に使用しても、オーバーヘッドはほとんど増加しないようです。

しかし、それ以上に、今後の対応はワークロードと現在のプロセッサの両方に大きく依存するようです。Skylake、Kaby Lake、Coffee Lakeプロセッサを搭載した一般的なデスクトップユーザーは、MeltdownとSpectreの両方の防御を安心して有効にできます。仮想化ホストやクラウドプロバイダーは、すべての保護機能を有効にする以外に選択肢がほとんどなく、プロセッサによってはretpolineだけでは対応できない可能性があります。

234件のコメント