GPUパススルーを使用する場合（ここ）？
ゲストが侵害された場合、GPUとそのファームウェアに永続的に感染する可能性がありますか？可能であれば、この侵害されたGPUは何をすることができますか？
- VT-d / IOMMUは仮想マシンにデバイスを安全に格納するように設計されていますが、ゲストはGPUを使用してホスト（OSまたはその他のデバイス）を危険にさらす可能性がありますか？
-
GPUが危険にさらされている疑いがある場合、理想的な行動方針は何ですか？コンピューターのホストOSが再インストールされた場合、GPUはそれを攻撃して感染させることができますか？
（別の質問に移動）
一般的な回答を探していますが、関連がある場合は、KVMとWindowsゲストを備えたLinuxホストを想定してください。
コメント
- githubに概念実証 GPUルートキットクラゲがあります。再起動後も存続しますが、シャットダウンは存続しません。
回答
-
ゲストの場合が侵害された場合、GPUとそのファームウェアに永続的に感染する可能性がありますか？
OpenStackによると、ドキュメント、はい。
多くのハイパーバイザーは、PCIパススルーと呼ばれる機能を提供します。これにより、インスタンスはノード上のハードウェアに直接アクセスできます。たとえば、は、インスタンスがビデオカードまたはGPUにアクセスできるようにするために使用でき、高性能計算用のコンピューティングユニファイドデバイスアーキテクチャ（CUDA）を提供します。
この機能には、ダイレクトメモリアクセスとハードウェア感染の2種類のセキュリティリスクがあります。
ダイレクトメモリアクセスは、IOMMUを使用しないデバイスパススルーにのみ関連します。
-
VT-d / IOMMUは仮想マシンへのデバイスを安全に封じ込めるように設計されていますが、ゲストはGPUを使用してホスト（OSまたはその他のデバイス）を危険にさらすことができますか？
デバイスがホストによって使用されている場合。
ハードウェア感染インスタンスがファームウェアまたはデバイスの他の部分に悪意のある変更を加えたときに発生します。 このデバイスは他のインスタンスまたはホストOSによって使用されるため、悪意のあるコードがそれらのシステムに拡散する可能性があります。最終結果は次のとおりです。その1つのインスタンスは、セキュリティドメインの外部でコードを実行できます。仮想ハードウェアよりも物理ハードウェアの状態をリセットするのが難しく、管理ネットワークへのアクセスなどの追加の露出につながる可能性があるため、これは重大な違反です。
コメント
- デバイスはホストによって"使用されていますか" VMのシャットダウン後？または、それ以外の場合は？
- 少なくとも、デバイスはBIOSによって"使用されます"次にホストマシンが再起動され、システム内のデバイスを特定しようとします。
- ハードウェア感染には、PCI構成スペースへのアクセス（オプションROMの書き込み）が必要だと思います。 ' CUDAが永続的なGPUに実際に"感染するのに十分だとは思いません"コード。