【再掲】【海外記事】 Gather Data Sampling

下記サイトのDeepL機械翻訳です。


ギャザー・データ・サンプリング(Gather Data Sampling:GDS)は、特定のインテル・プロセッサーに影響を及ぼす、一過性の実行サイドチャネル脆弱性である。ギャザー命令がメモリから特定のロードを実行する場合、悪意のある攻撃者がこのタイプの命令を使用して、以前に使用されたベクターレジスタ1からの古いデータを推測することが可能な場合があります。 これらのエントリは、同じスレッド、または同じプロセッサコア上の兄弟スレッド2によって以前に使用されたレジスタに対応する可能性があります。

GDSは、マイクロアーキテクチャ・データ・サンプリング(MDS)のようなデータ・サンプリング一時実行攻撃と同様に、システム上でローカルにコードを実行できる悪意のある行為者に、アーキテクチャ・メカニズムによって保護されている秘密データの値を推測させる可能性があります。GDS が MDS 脆弱性と異なるのは、暴露の方法(ギャザー命令のセットに限定される)と暴露されるデータ(古いベクター・レジスタ・データのみ)の両方です。MDS も GDS も、それ自体では、悪意のある行為者に、これらの方法を使用して推論されるデータを選択する能力を与えない。

GDSにはCVE-2022-40982が割り当てられており、CVSS Base Scoreは6.5(中) CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:Nです。

インテルは、GDSを緩和するためのマイクロコードアップデートを提供している。ミティゲーションを有効にするためにソフトウェアを変更する必要はありません。ミティゲーションにより特定のワークロードでパフォーマンスに影響がある場合、ソフトウェア制御を使用してミティゲーションを無効にすることが可能な場合があります(詳細については、「ソフトウェアとデプロイメントのガイダンス」セクションの例、またはソフトウェアベンダーのリリース情報を参照してください)。その他の情報については、「性能に関する考慮事項」のセクションを参照してください。

この文書に記載されているマイクロアーキテクチャの詳細は、GDS の影響を受けるプロセッサーに適用されるものであり、すべてのプロセッサーに普遍的であると考えるべきではない。詳細については、「影響を受けるプロセッサ」のセクションを参照してください。

システム管理者、アプリケーション開発者、およびユーザーは、GDS を軽減するかどうか、またどこで軽減するかを決定する際に、システムに適用される脅威モデルを注意深く考慮する必要があります。ユーザーは、環境脅威モデルに基づいて、オペレーティング・システム・ベンダー (OSV) が提供するオプションを使用して GDS 緩和機能を無効にすることができます。インテルは、管理されたラボ環境以外でこの脆弱性が悪用された例を認識していません。

インパクト・サマリー

悪意のあるソフトウェアは、同じスレッド、または同じ物理コア上の兄弟スレッドで使用されているベクターレジスター1 に以前保存されていたデータを推測できる可能性があります。これらのレジスタは、他の仮想マシン (VM) ゲスト、オペレーティング・システム (OS) カーネル、インテル® Software Guard Extensions (インテル® SGX) エンクレーブなど、他のセキュリティ・ドメインによって使用されている可能性があります。インテル® トラスト・ドメイン拡張 (インテル® TDX) をサポートするプロセッサーは、GDS の影響を受けません。

背景と課題

Gather は、インテル® Advanced Vector Extensions 2 (インテル® AVX2) およびインテル® Advanced Vector Extensions 512 (インテル® AVX-512) が提供する機能です。これは、ベクター・インデックス・メモリ・アドレッシングを使用してメモリから非連続のデータ要素をフェッチする単一命令、複数データ(SIMD)命令のコレクションで構成されています。

ギャザー命令がメモリからロードを実行するとき、異なるデータ要素は指定されたマスクに従って宛先ベクタレジスタにマージされます。状況によっては、ギャザー命令特有のハードウェア最適化により、アーキテクチャまたは内部ベクタレジスタの以前の使用による古いデータが、ギャザーロードによって更新されることなく、依存命令に一時的に転送されることがあります。このような依存命令により、悪意のある攻撃者は、共有CPUキャッシュのような秘密のチャネルを通じて転送されるベクタレジスタの古いデータを推測できる可能性があります。

この動作によって古いデータが露出する範囲は、同じ物理プロセッサ・コアに限定されます。ローカル・コード実行能力を持つ攻撃者は、同じ物理プロセッサ・コアのステール・データをサンプリング・ベースで観察することはできますが(この意味で、GDSはデータシートと似ています)、推論されるデータを直接制御したり指定したりすることはできません。

GDS攻撃を使用して古いデータを推測するには、悪意のあるコードがギャザー命令を使用する必要があります。しかし、GDS攻撃はギャザー命令を使用しないソフトウェアにも影響を与える可能性があります。このような攻撃は、アーキテクチャー・ベクター・レジスタを明示的に使用する命令(SIMD命令やスカラーSSE命令、インテルAVX命令など)や、内部ベクター・レジスタを暗黙的に使用する命令(REP MOVS命令など)で処理されたデータを暴露する可能性があります。

軽減オプション

インテルは、攻撃者コードがギャザー・ロードの投機的な結果を観測するのを防ぐため、ギャザー命令の一時的な結果をブロックするミクロコードのアップデートをリリースする。パッチがロードされるとミティゲーションが有効になり、ハイパースレッディングが有効でもクロススレッドへの暴露が緩和される。

ミティゲーションが有効な場合、ギャザーロードの結果が消費されるまでに追加の待ち時間が発生します。ほとんどのワークロードのパフォーマンスへの影響は最小限ですが、特定のワークロードでは、最大50%のパフォーマンスへの影響が見られる場合があります。脅威モデルによっては、ミティゲーションをオプトアウトすることも可能である。

マイクロコードの緩和

ミティゲーションは、マイクロコードの更新時にデフォルトで有効になる。マイクロコードの更新は、ソフトウェアがミティゲーションをオプトアウトできるようにする MSR インターフェイスを提供する。

これは、IA32_MCU_OPT_CTRL MSR の GDS_MITG_DIS(ビット 4)と GDS_MITG_LOCK(ビット 5)がサポートされていることを示す。こ れ ら の ビ ッ ト を使用す る こ と で、 ソ フ ト ウ ェ アは ミ テ ィ ゲーシ ョ ンの現在の状態を判断 し 、 ミ テ ィ ゲーシ ョ ン を無効にで き る 可能性があ り ます。

これらの制御の詳細については、MSR 制御と列挙のセクションを参照してください。

インテル® ソフトウェア・ガード・エクステンション (インテル® SGX)

GDS の影響を受けるプロセッサーでは、インテル SGX が有効でハイパースレッディングが無効になっている場合、更新されたマイクロコードをロードすることで、インテル SGX エンクレーブに対する GDS を使用した直接攻撃の可能性が緩和されます。

インテル SGX 対応の影響を受けるプロセッサーには、インテル SGX TCB リカバリーがあります。この TCB リカバリーは、パッチが FIT ロードされ(例えば、BIOS が更新され)、BIOS によってインテル SGX が有効化され、ハイパースレッディングが無効化されている場合にのみ、最新であることが証明されます。この構成では、ミティゲーションは有効な状態にロックされます。インテル® SGX が有効でない場合、またはハイパースレッディングが有効な場合、ミティゲー ションはロックされず、システムソフトウェアが GDS ミティゲーションを有効または無効にするこ とができます。

インテル・キー・ロッカー

GDS が Key Locker ハンドルの背後にあるキー値を推測できる可能性があります。キー・ロッカーに対応するプロセッサーは、Tiger Lakeマイクロ・アーキテクチャーの第11世代インテル® Core™プロセッサーのみです。Tiger Lake システムでは、GDS ミティゲーションが有効(IA32_MCU_OPT_CTRL [GDS_MITG_DIS] (bit 4) が 0)でロック(IA32_MCU_OPT_CTRL [GDS_MITG_LOCK](bit 5) が 1)されていない限り、システムソフトウェアが(CR4.KL を設定して)Key Locker を有効にしないことを推奨します。こ れに よ り 、 シ ス テ ム を制御す る 侵入者が、 キー ロ ッ カーのハン ド ルの背後にあ る キーを推測す る ために ミ テ ィゲーシ ョ ン を オ フ にす る こ と を防ぐ こ と がで き ます。

キー・ロッカーの GDS ミティゲーション・ロッキングをサポートするため、Tiger Lake システムのマイクロコード・アップデートは、GDS_MITG_LOCK に対して以下のモデル固有の動作を有効にします。これらのシステムでは、GDS_MITG_DIS(ビット 4)の値が 0、GDS_MITG_LOCK(ビット 5)の値が 1 で IA32_MCU_OPT_CTRL MSR に書き込むと、リセットされるまでこれらの値で両方のビットがロックされます。 ロックされていない場合、これらのビットに [5:4] = 10b 以外の値を指定して IA32_MCU_OPT_CTRL に書き込んでも、GDS_MITG_LOCK の値には影響しません。 一度ロックされると、それ以降のGDS_MITG_DISおよびGDS_MITG_LOCKへの書き込みは無視される。

インテル® トラスト・ドメイン・エクステンション(インテル® TDX)

インテルTDXをサポートするプロセッサーは、GDSの影響を受けません。

ソフトウェア・シーケンス

ベクタ・レジスタ・スクラビング・ソフトウェア・シーケンスセクションでは、特定の状況下で、マイクロコー ドの緩和と組み合わせて使用できる、古くなったベクタ・レジスタ・データをスクラブするためのソフ トウェア・シーケンスについて説明します。

ソフトウェアと配備ガイダンス

このセクションでは、オペレーティング システム ベンダー(OSV)、仮想マシン マネージャー(VMM)、およびシステム オペレーターを対象に、GDS ミティゲーションのパフォーマンス、脅威分析、システ ム ソフトウェアによる列挙と制御の管理方法、およびミティゲーションをオプトアウトする方法が、シ ステムの潜在的な暴露のしきい値と脅威モデルの範囲内である場合のガイダンスを示します。

脅威分析

ユーザーは、ミティゲーションのオプトアウトを決定する際に、性能の考慮に加えて、用途と脅威モデル、信頼と資産のレベルを考慮する必要がある。データサンプリング収集のための脅威分析ガイダンスの追加ガイダンスを参照のこと。

パフォーマンスに関する考察

ほとんどのワークロードに対するパフォーマンスへの影響は最小限ですが、GDS ミティゲーショ ンを有効にすると、特定のワークロードでパフォーマンスに大きな影響が出る場合があります。コンパイラーは多くのアプリケーションでギャザー命令を生成しますが、多くの作業負荷は関連するギャザー命令を使用しないか、またはホットパス(頻繁に実行されるコード)の一部としてそれらの命令を含まないため、ミティゲーションによる性能への影響は観測されません。性能に影響が出る可能性が最も高いワークロードは、ホットパスでギャザー命令を多用する特定のハイパフォーマン スコンピューティングやグラフィックスのワークロードです。詳細については、コンパイラの最適化セクションを参照してください。

伝統的に、性能を最適化するためにギャザー命令に依存するアプリケーションは、CPU使用率が非常に高く、ベクトル化を可能にする特性を持ち、これらのベクトル拡張を利用するために慎重に調整され最適化される傾向があります。これらは通常、特定のタイプの科学、グラフィックス、エンジニアリングアプリケーションです。ソフトウェア開発者は、コンパイラがそのような命令を生成できるように、あるいは開発者自身がインライン・アセンブリ・コードやイントリンシックを通じてそのような命令を含めることができるように、慎重にコードを構成しなければなりません。ギャザー命令を生成するように設計または最適化されていないソフトウェアでも、コンパイラはギャザー命令を生成できるかもしれない。

自分のコンピュータの作業負荷と使用状況を理解しているエンドユーザーは、CPUを多用し、ベクトル化を多用するアプリケーションのいずれかがマイクロコードの更新によって影響を受けるかどうかを判断することができます。perfmon のようなユーザーツールは、パフォーマンスへの影響の原因を発見するのに役立ちます。詳細については、OS の設定ドキュメントを参照するか、デバッグ環境で MSR を有効または無効にする方法については、Linux* における MSR の読み取りと書き込みのガイドを参照してください。

ソフトウェアの変更

ギャザー命令を回避するようにチューニングされたコンパイラ構成でソフトウェアを再コンパイルす ることにより、影響を受けるワークロードにおける GDS 緩和のパフォーマンスへの影響の大部分を 軽減することが可能です。詳細については、「コンパイラの最適化」のセクションを参照してください。ソフトウェアのパフォーマンスが GDS ミティゲーションによって影響を受けない場合、または GDS ミティゲーションが無効になっているシステムでのみソフトウェアが実行される場合、ソフトウェアを再コンパイルする必要はありません。

信頼されていないゲストVMでGDSミティゲーションが無効になる可能性がある場合、VMからVMへの移行ケースで、古いベクターレジスタデータをスクラブするためのソフトウェアシーケンスを考慮することがあります。詳細については、ソフトウェア緩和シーケンスのセクションを参照してください。

clwb命令のパフォーマンスに関する考慮事項

影響を受けるプロセッサの特定のサブセットでは、GDS の緩和をサポートするマイクロコードの更新が clwb 命令のレイテンシにも影響します。

表1:GDS緩和がCLWBレイテンシに影響を与えるプロセッサ

clwb(Cache Line Write Back)命令は、キャッシュ階層にキャッシュ・ラインが存在する場合、変更されたデータでメモリが更新されるようにするために使用できます。 類似の clflushopt 命令とは異なり、clwb のセマンティクスでは、キャッシュ・ラインのコ ピーを変更されていない状態で保持することが可能です。しかし、表 1 のプロセッサでは、clwb も clflushopt も常にキャッシュ行を完全に無効にします。

GDS の緩和策に clwb 命令の変更が含まれるインテル・プロセッサーでは、clwb を多用するアプリケーショ ンでパフォーマンスへの影響が見られる可能性があります。このようなアプリケーションは、特定の永続メモリ対応データベース、不揮発性メモリ上で動作する重い I/O アプリケーションやライブラリなど、不揮発性メモリの特定のユースケースであると予想されます。そのようなアプリケーションは、clwbのインスタンスをclflushopt命令で置き換えるかもしれない。 このサブセットのプロセッサでは、clwb命令とclflushopt命令は同等の動作をしますが、clflushoptのレイテンシはマイクロコードの更新の影響を受けません。

Cascade LakeまたはCooper Lakeというコード名のプロセッサでは、GDS_MITG_DISを設定してGDS緩和機能を無効にすると、clwb命令のレイテンシへの影響はなくなります。

OSコントロール

GDS ミティゲーションは、マイクロコードパッチがロードされるとデフォルトで有効になる。セキュリティとパフォーマンスへの影響に基づき、ソフトウェアを使ってミティゲーションを有効または無効にすることができるかもしれません。

リナックス

本セクションでは、GDS ミティゲーションに対する Linux サポートの現在の計画について説明します。このサポートは現在のカーネルには存在せず、詳細(コマンドラインフラグやファイル名など)は変更される可能性があります。

インテルは、オープンソースのエコシステムと協力して、Linuxカーネルのコマンドラインパラメーターgather_data_samplingを追加し、このミティゲーションを簡単に無効化できるようにする予定です。このパラメータに関する現在の計画は、既存の Linux カーネル緩和策と同様に、表 2 に示すとおりです。このブートタイムパラメータを使用することが、このミティゲーションをオプトアウトするための推奨方法です。カーネルブートパラメータの設定は、Linuxディストリビューションによって異なる場合があります。例えば、Ubuntu*の説明はここに、Fedora*の説明はここにあります。カーネル・ブート・パラメーターの変更方法については、OSVにお問い合わせください。

表2:GDS緩和管理用カーネルブートパラメーター

パラメータ「mitigations=off」を設定すると、Linuxカーネルのドキュメントに記載されているGDSミティゲーションも無効になります。

デフォルトのアップストリームカーネルコンフィギュレーションでは、デフォルトでミティゲーションが有効になっています。

最新のLinuxシステムでは、/sys/devices/system/cpu/vulnerabilities/gather_data_samplingファイルからミティゲーションステータスを読み取ることができます。

この他にも、MSR の制御と列挙のセクションに記載されている MSR を操作することで、特権ユーザがミティゲーションを管理できるオプションがあります。しかし、これらの変更は永続的ではないかもしれない。OSVからGDSオプトアウトオプションがまだ利用できない場合は、この列挙を参照し、OSVと協力してこれらのMSRをどのように処理するかを特定してください。例えば、msr-toolsは、特権ユーザーのオプションとなりうる方法でMSRを処理することができます。

ウィンドウズ

インテルは、マイクロソフト社*と協力し、Windows OSのカーネルに、特定の状況下でGDS脆弱性の緩和策を無効にする選択肢を提供するメカニズムを提供するための作業を継続しています。これは今後のリリースで更新される予定です。

その他のオペレーティングシステム

GDS 脆弱性ミティゲーションは、インテル製ハードウェアではデフォルトで有効になっているため、ソフトウェアベンダーや OSV は、GDS 脆弱性の脅威にさらされる可能性が低いお客様向けに、ミティゲーションを無効にするためのさまざまな設定オプションを提供しています。特定の OS でミティゲーションをオプトアウトする方法については、「参考文献」のセクションを参照するか、 ソフトウェアベンダーのプロバイダーにお問い合わせください。

仮想化

ハイパーバイザー(VMM)は、IA32_ARCH_CAPABILITIES[GDS_CTRL | GDS_NO](ビット25および26)およびIA32_MCU_OPT_CTRL [GDS_MITG_DIS | GDS_MITG_LOCK](ビット4および5)の両方をホストまたはルートパーティションに列挙して、許可されたユーザーがルートOSによって提供されるコントロールを使用してミティゲーションを有効または無効にできるようにする必要があります。ユーザは、このような制御はグローバルであり、システム上のすべての VM に影響することを認識する必要があります。

VMのオーナーは、自分のVMがGDSの影響を受けるかどうかを知りたいと思うかもしれない。ハイパーバイザーは、GDS_NO ビットだけをゲストに公開する方法と、IA32_ARCH_CAPABILITIES および IA32_MCU_OPT_CTRL で完全な列挙を公開する方法の 2 通りの方法で、この情報を VM に公開することができます。VMM は IA32_MCU_OPT_CTRL をゲストに公開することで、ゲストのソフトウェアがマイクロコードのミティゲーションが有効になっているかどうかを判断し、パフォーマンスに影響を与える可能性のある命令を集めることができます。VMM が GDS_NO のみを公開することを選択した場合、VMM は、プロセッサが GDS_NO について報告する内容と、更新されたマイクロコードを実行している影響を受けるプロセッサにおけるミティゲーションの状態に基づいて、その値を合成する必要があります。

VMM が IA32_MCU_OPT_CTRL インターフェースをゲストに公開し、ゲストがミティゲーションを無効化できないようにする場合は、GDS_MITG_LOCK の値を 1 として報告する必要があります。そのような状況の 1 つは、リスクを考慮した上で許可する場合です。また、VMM がベクター・レジスタ・スクラビング・ソフトウェア・シーケンスを使用できる場合 も考えられます。VMM がベクター・レジスタ・スクラビング・ソフトウェア・シーケンスを使用できる場合:

VMM は、現在の VM が GDS ミティゲーションの無効化を要求している場合を除き、常にマイクロコー ドのミティゲーションを有効にします。
VMM は、GDS ミティゲーションの無効化を要求した VM に切り替わるたびに、マイクロコー ドのミティゲーションを無効化し、ソフトウェア・シーケンスを実行する。
シークレットフリー VMM として知られる)VMM レベルで他のゲストからのシークレットデータへのアクセスを防止するメカニズムを実装している VMM では、VMM が同じ物理コア上で別の信頼できないゲストをスケジュールするまでは(VM が終了してコアが再割り当てされる場合を含む)、ソフトウェアシーケンスを実行する必要なく、ゲストがミティゲーションを無効にすることができます。

このシナリオでは、VMM がすべての VM を CPU コアでスケジューリングしていると仮定しています。ミティゲーションが有効になっている VM に切り替えた場合は、ソフトウェアシーケンスを実行する必要はありません。GDS_MITG_DISビットまたはGDS_MITG_LOCKビットをサポートしていないプロセッサ上で実行されているVMMでも、仮想化するためにIA32_MCU_OPT_CTRLへのMSRアクセス時にVMの終了を引き起こす可能性があることに注意してください。

VMMはまた、一部のゲストまたはすべてのゲストに対してclwb命令を列挙するかどうかを検討する必要があります。 これは、この命令を列挙しないことで、ゲストはこの緩和の影響を受けない代替のキャッシュフラッシュ命令に頼らざるを得なくなるためです。

MSR の制御と列挙

インテルは、GDS 緩和のソフトウェア制御をサポートするマイクロコードアップデートをリリースします。IA32_MCU_OPT_CTRL MSR と IA32_MCU_OPT_CTRL[GDS_MITG_DIS](ビット 4)および IA32_MCU_OPT_CTRL[GDS_MITG_LOCK](ビット 5)のサポートは、IA32_ARCH_CAPABILITIES[GDS_CTRL](ビット 25)によって列挙されます。

IA32_ARCH_CAPABILITIES[GDS_NO](ビット26)が1を報告する場合、このプロセッサがGDSの影響を受けないことを示す。すべての影響を受けないプロセッサがGDS_NOを1として列挙できるわけではないことに注意。また、Intel AVXがサポートされていない場合、この攻撃は不可能であることに注意してください(Gather命令のサポートはIntel AVXの状態が有効であることが条件となるため)。

GDS_CTRLは、この攻撃が不可能なプロセッサーでは列挙されないか、サポートされないかもしれない。

表3:IA32_MCU_OPT_CTRL MSRのアップデート
表4:IA32_ARCH_CAPABILITIES MSRのアップデート

影響を受けるプロセッサー

この問題の影響を受ける、現在サポートされているプロセッサの一覧については、影響を受けるプロセッサの統合表(「2022-2023」タブの「Gather Data Sampling」列)を参照してください。影響を受けるプロセッサーは、最新のマイクロコードをロードして GDS 緩和を有効にする必要があります。

ベクター・レジスタ・スクラビング・ソフトウェア・シークエンス

このセクションでは、特定のプロセッサで未使用のベクタ・レジスタ・ファイル・エント リの内容をスクラブするために使用できるソフトウェア・シーケンスについて説明します。これは、前のセキュ リティドメインから信頼されていないセキュリティドメインに切り替えた時(例えば、 VMM が相互に信頼されていないゲスト間で切り替えた時など)に、そのセキュリティドメ インの実行中に GDS ミティゲーションが有効にならない(例えば、GDS_MITG_DIS MSR が 1 に設定されている)ソフトウェアに役立ちます。

ハイパースレッディングが有効になっている場合は、以下に説明するように、SMT を考慮したバージョンのシーケンスを使用する必要があります。同様に、信頼されていないセキュリティ・ドメインがインテル AVX-512 命令を実行できる場合は、インテル AVX-512 バージョンのシーケンスを使用する必要がある。

このソフトウェア・シーケンスはアーキテクチャー的に保証されているものではなく、特定のアーキテクチャーおよびマイクロアーキテクチャー条件下でのみ有効です。このシーケンスを使用するソフトウェアは、実行時間を使用して、そのような中断が発生したかどうかを観察しようとすることができる。

ソフトウェア・シーケンスの概要

以下の図は、SMTが有効な場合(図1)と無効な場合(図2)のソフトウェア・シーケンスの概要を示している。SMTが有効な場合、スレッド0とスレッド1は同じ物理コアのスレッドであり、スレッド0を "プライマリスレッド"、スレッド1を "セカンダリスレッド "と呼ぶ。プリシーケンス」ステップでは、アーキテクチャ・レジスタに対応するベクタ・レジスタ・エントリが確実にスクラブされ、「コアフロー」ステップでは、未使用のベクタ・レジスタ・ファイル・エントリのスクラブが行われます。

図1:SMTを有効にした場合のベクター・レジスタ・スクラビング・ソフトウェアのシーケンス
図2: SMTを無効にしたベクター・レジスタ・スクラビング・ソフトウェア・シークエンス シーケンスはx87とIntel AVXの両方の状態を変更するため、実行中はx87とIntel AVXの両方を有効にする必要があります。さらに、x87 および Intel AVX レジスタの内容は保存し、必要に応じてシーケンスの後に復元する必要があります。

前提条件

プリシーケンスは、アーキテクチャ・レジスタに対応するベクタ・レジスタ・ファイ ル・エントリのデータをすべてスクラブする役割を果たします。これは、全幅データ(インテル AVX-512 がサポートされている場合は 512 ビット、そうでない場合は 256 ビット)をすべてのベクター・レジスタに書き込むことで保証されます。他の関連するマイクロアーキテクチャー構造もスクラブされるように、プリシーケンスの後にVERWを呼び出すとよいでしょう。

インテルは以下のプリシーケンスコードを推奨している:

命令キャッシュ・ミスなどの要因がシーケンスのタイミングに与える影響を最小限に抑えるため、プリシーケンスはプライマリー・スレッドでコア・フローを実行することで「ウォームアップ」を行うことができる。

シーケンス・コアの流れ

シーケンス本体は、GDSの影響を受けるベクターレジスタのスクラブ(妨害されてはならない "コアフロー")を実行するシーケンスの一部である:

ベクトル実行状態のクリア:

"バースト "シーケンスで未使用のベクタレジスタエントリを消去します。この例では、2つのIntel AVX-512命令を256回繰り返します:


シーケンス本体の最初と最後におけるクロススレッド同期のための "同期と待機のループ":

中断の検出

ソフトウェアは、シーケンスの "コアフロー "の実行時間を測定することで、中断の検知を試みることができる。シーケンスの実行に予想よりも著しく時間がかかる場合、ソフトウェアはシーケンスが中断されたと仮定することができ、その後、シーケンス本体を再度実行する必要があります。このような中断は、シーケンスがすべてのベクタ・レジスタ・ファイル・エントリをクリアできな かったことを意味するかもしれない。実行が中断された後でも、ベクタレジスタファイルエントリが消去されずに残る可能性は低くなるため、ソフトウエアは、過剰な実行時間を避けるために、シーケンスの最大再試行回数を制限することを検討するとよいであろう。

実行時間を測定するには、rdpmc命令を使用して固定コア・サイクル・カウンタを読み取ります。インテルは、クロススレッド同期を含むシーケンス本体(「コアフロー」)全体を測定することを推奨している。

インテル AVX-512 バージョンのシーケンスが使用されているが、ソフトウェアが最近インテル AVX-512 命令を使用していない場合、電圧ガードバンドの制限により、ソフトウェアシーケンス (およびその他のコード) の実行が一定時間遅くなることがあります。

パフォーマンス・カウンターや割り込みカウンターを使用するなど、別の方法で障害を検出することもできますが、インテルでは、可能な限りタイミングベースのアプローチを使用することを推奨しています。SMT が有効な場合、中断を検出するための追加データポイントとして、「同期と待機のループ」の繰り返し回数を測定することを検討できます。

コンパイラの最適化

コードによっては、ギャザー命令を使用せずベクトル化を適用したままリコンパイルしたバイナリの方が、ギャザー命令を使用しGDS緩和を有効にした場合よりもパフォーマンスへの影響が少ない場合があります。コンパイラによっては、最終的なバイナリでギャザー命令を生成しないようにするため のさまざまなフラグが用意されている場合があります。これが可能かどうかについては、コンパイラのドキュメントを参照してください。

コンパイラーは、ソフトウェアスタックのリコンパイルされた部分でギャザー命令を回避すること ができます。アプリケーションの他の部分(例えば、サードパーティ・ライブラリ)は、対応するパフォーマ ンス・セキュリティの影響を持つギャザー命令を含み続けるかもしれません。そのため、コン プライア最適化は完全なセキュリティ緩和策ではなく、ハードウェア緩和策を適用すること だけで起こりうるパフォーマンスへの影響を緩和するものです。したがって、最もセキュアで高性能なオプションは、ハードウェアによる緩和とコンパイラによる緩和オプションを組み合わせることです。以下に、さまざまなコンパイラを使用して、生成されたコード内のギャザー命令を回避するオプショ ンを示します:

表5:GDS緩和コンパイラー・オプション

この場合、ソースコードを再コンパイルする必要があるため、アプリケーションが再コンパイルできないサードパーティーライブラリーを使用している場合、サードパーティーライブラリーにギャザー命令が含まれていれば、これらのコンパイラーフラグを設定しても影響はありません。リコンパイルされたコードであっても、現在のところ gather 組み込み関数は gather 命令を生成し続けます。ホットパスのギャザー命令のほとんどがサードパーティーライブラリーではなくメインアプリケー ションにある場合、アプリケーションはリコンパイルした方がよい場合があります。

用語

ステールレジスタ: Stale registers:古いレジスタ(以前に使用された値)を保持するレジスタファイルのエントリ。

Vector Registers (ベクター・レジスタ): ベクトル計算のオペランドと結果を格納するCPUコア内の記憶領域。ベクトル以外の演算で使用される一時的な値を保持することもある。



参考


この記事が気に入ったらサポートをしてみませんか?