PCIe のファジング : GPU 導入に向けたセキュリティ検証と対策

私たち Google は先ごろ、Google Cloud Platform（GCP）で GPU の提供を開始しました。このハードウェアは高並列ワークロードの処理に活用できます。GPU は各種の PCI Express（PCIe）スイッチを介して Google のクラウド マシンに接続されるため、私たちは GPU を導入するにあたって PCIe のセキュリティを深く把握しておく必要がありました。

PCIe デバイスのセキュリティを確保するには固有の問題を克服しなければなりません。GPU はここ数十年で極めて複雑になっており、新たな攻撃の手口が現れるおそれがあるのです。

GPU はシステム メモリに直接アクセスするように設計されていますが、これまでこの種のハードウェアは信頼できるのが当たり前のように考えられてきたため、GPU を安全に動作させるための設定がすべて正しく行われていることを確認するのは困難です。しかも、そうした設定が機能するかどうかを確認することすら難しいというのが実情です。

また、GPU メーカーは GPU のメイン プロセスのソース コードやバイナリを提供していないので、私たちはこれらを自信を持って検証することができません。PCI と PCIe の仕様から読み取れる問題については、こちらで解説をご覧になれます。

PCIe デバイスが侵害されると、悪意ある動作をするおそれがあります。したがって、Google としてはその種の攻撃への対策を講じる必要がありました。これらのデバイスはクラウド サービスで提供され、不特定多数の人が仮想マシンで利用するのですから、なおさらです。

私たちがとったアプローチは、リスクの軽減に重点を置いています。「侵害された PCIe デバイスが、他のコンピュータのセキュリティを危険にさらさないようにする」というものです。

ファジングによる脆弱性の検出

PCIe の仕様を初めて調査した後、私たちはエッジ ケースと、結果が明確に定義されていないデバイスの動作リストを用意しました。それらの動作を実際のハードウェアでテストしたいと考えたからです。

また、仕様の中で明確に定義されている部分が実際のハードウェアで適切に実装されているかどうかも調べたいと考えました。実のところ、ハードウェアにバグがあるのはよくあることですが、セキュリティ担当者の多くはバグはないと思い込み、メーカーを信頼しています。

私たちが目指していたのは、ハードウェアを含めたスタックのすべてのレイヤを検証することでした。その計画を実行に移すためには、私たちがクラウド ハードウェアで使用する本番環境の構成に対して効果を発揮するように設計された、非常に特殊なファザーが必要でした。私たちはクラウド マシンでさまざまな GPU とスイッチの組み合わせを使いますので、プログラマブルなネットワーク インターフェース コントローラ（NIC）を同様の構成でセットアップし、GPU のメモリ アクセスをシミュレートしました。

私たちのファザーはこうした各 NIC から、アップストリーム ポートを直接叩くか、ネットワーク上のアクセス可能なすべてのポートを執拗に叩くことで、メモリのさまざまな読み書きを行いました。これらのオペレーションには、標的型攻撃やランダム読み書きに加えて、多くのハードウェア アーキテクチャ上で問題を引き起こす傾向がある “ラッキー ナンバー” の読み書きの組み合わせが含まれていました。

私たちは、ファジングによるポート構成の変更、特にポートのセカンダリ バス番号と下位バス番号の変更の発生を検知しようとしました。Source Validation を有効にした PCIe ネットワークは、主にこれらのバス番号で管理されます。これらの番号によって、パケットの送信可能な宛先が決まります。ポートのセカンダリまたは下位バス番号が再構成できれば、PCIe ネットワーク内のアクセスされてはならない部分にアクセスできる可能性があります。

私たちのセキュリティ チームは、疑わしいメモリ読み取りや書き込みを調査し、それらがセキュリティ脆弱性の表れかどうかを判断したうえで、それに応じてファザーか PCIe の設定を調整しました。

その結果、潜在的な問題がいくつも見つかりました。たとえば、ある誤った構成では、スイッチ上の文書化されていないデバッグ レジスタが、誤ってダウンストリーム デバイスに丸見えになっていました。

この状態は、特定のアクセス パターンのもとで、スイッチの深刻な誤動作を引き起こす可能性があることを、私たちは発見しました。デバイスが接続先スイッチの仕様外の動作を引き起こしうる場合は、安全でないルーティングを実行させてしまうおそれもあり、そうなればネットワーク全体が危険にさらされます。

ファジングの価値は、仕様で定義された一連の正常な動作やオペレーションの枠を超えて、文書化や定義がなされていない領域の脆弱性を発見できることにあります。私たちはファジング プロセスを経て、クラウドで GPU を安全に動作させるために最小限必要な Access Control Services（ACS）機能セットを決定できました。ACS は PCIe で提供される機能です。

メモリ マッピングもチェック

仮想マシンを初期化すると、一連のページ テーブルがゲストの物理メモリをホストの物理メモリにマップします。ただし、GPU はこのマッピングを認識できないため、誤った場所に書き込もうとします。

そこで、Input/Output Memory Management Unit（IOMMU）の出番となります。IOMMU はページ テーブルであり、GPU からのアクセスを DRAM/MMIO に対する読み書きに変換します。また、ハードウェアに実装されており、再マッピングのオーバーヘッドを軽減します。

このことは、IOMMU が非常に繊細なオペレーションを行っていることを意味します。自身の仮想 I/O アドレスをホストの物理アドレスにマップしているわけです。私たちは、IOMMU が正しく機能していることを検証し、デバイスが信頼できないコードを実行しても、IOMMU が有効になっていれば、不正なメモリ アクセスが発生する可能性はないことを確認したいと考えました。

ところが、IOMMU はその一方で、互換割り込みのような望ましくない機能も備えています。互換割り込みは、IOMMU が提供する割り込みの再マッピング機能を持たない古い Intel プラットフォームをサポートするための機能です。この機能は、最近のハードウェアには必要ありません。互換割り込みを有効にすると、ゲストが予期せぬ Message Signalled Interrupt（MSI）や、マシンの再起動、ホストのクラッシュを引き起こしてしまうおそれがあります。

ここで最も興味深い問題は、PCIe の Address Translation Services（ATS）の悪用を防ぐことです。どのデバイスもこの機能を使えば、自身が変換済みのアドレスを使用していると主張し、IOMMU のアドレス変換を回避してメモリ書き込みを行えます。

ATS は、信頼できるデバイスにおいてはパフォーマンスを高める有効な方法です。しかし、信頼できないデバイスがこの機能を使うと、大きなセキュリティ脅威となります。侵害されたデバイスが ATS によって IOMMU を無視し、アクセスしてはならない場所に書き込みを行ってしまうおそれがあるからです。

幸い、どのようなデバイスにも ATS を無効にできる ACS 設定があります。そのため、私たちは互換割り込みと ATS を無効にし、ファザーを使ってメモリ上のマップされた領域の外部へのアクセスを試みました。そして徹底的なテストを行い、IOMMU が宣伝どおりに機能し、悪意あるデバイスがこれを回避することはできないことを確認しました。

まとめ

ACS と IOMMU は、スタックのさまざまなレイヤで有効または無効に設定されることになります。カーネルのバージョンや、デバイスのデフォルト設定、ちょっとした調整によって異なる設定がなされる可能性があります。独立した単体テストに頼って、こうした設定を網羅して確認するのは極めて難しいと言わざるをえません。そこで私たちは、本番環境で ACS と IOMMU の設定を監視するツールを開発しました。システムの構成ミスを迅速に検知し、修正するためです。

ハードウェアに関しては、正常に動作することを確認できるまでは、信頼しないに越したことはありません。私たちは標的型攻撃と強力なファジングにより、GPU をクラウド ユーザーと安全に共有するための ACS 設定リストを完成させました。その結果、基盤となるシステムのセキュリティについて高い信頼性を確保したうえで、GPU をお客様に提供できています。

今後も、Google Cloud におけるセキュリティの実装方法を解説した記事をお届けしていきます。どうぞお楽しみに！

* この投稿は米国時間 2 月 9 日、Software Engineer である Julia Hansbrough によって投稿されたもの（投稿はこちら）の抄訳です。

- By Julia Hansbrough, Software Engineer