RISC-V TEE の SoC レベルのセキュリティ モジュール - IOPMP の簡単な分析

序文

アーキテクチャの分野では、セキュリティの問題は常にホットなトピックであり、記事「RISC-V プロセッサのセキュリティの課題 - アーキテクチャの脆弱性と攻撃リスクの簡単な分析」では、最新のプロセッサのマイクロアーキテクチャの設計で遭遇するキャッシュ サイドチャネル攻撃について詳しく説明しています。 、メモリ脆弱性攻撃、その他のセキュリティ上の課題について説明し、これらのアーキテクチャ上の脆弱性に対して学界や産業界が提案する防御策をまとめています。

前述の記事は主にプロセッサ コア内のセキュリティに焦点を当てているため、この記事では別の角度から始めて、RISC-V プロセッサ コアの外側に現在存在するセキュリティの問題を明らかにし、セキュリティを確保するために使用される方法に焦点を当てます。 RISC-V SoC システムのセキュリティ 新しいモジュール - IOPMP。

1. IOPMP の背景

この記事のタイトルを見ただけの読者は、必ず 3 つの疑問を心に抱くでしょう。IOPMP とは何ですか? IOPMP と PMP の違いは何ですか? TEE に IOPMP が必要な理由は何ですか? 心配しないでください。すべてのストーリーは TEE のコンセプトから始めることができます。

1.1 TEE の概要

Linux、Android、IOSなどのよく知られた一般的なオペレーティングシステムは、豊富なユーザーインターフェースや管理機能を提供するため、リッチOSとも呼ばれます。これらのリッチOSが動作するシステム環境は、それに対応してREE(Rich Execution Environment)と呼ばれます。 。比較的オープンなREE環境を基盤として、開発者は柔軟にアプリケーションを開発し、独自のビジネスを展開することができますが、その分、マルウェアが機密データの窃取、決済パスワードの窃取、デジタル著作権の悪用などを試みる可能性があり、深刻な脅威となっています。 . ユーザー情報と財産のセキュリティ。さらに、オペレーティング システムのコードのサイズが年々増大するにつれて、リッチ OS 自体のセキュリティ上の脆弱性も常に発生しており、このいたちごっこのバグ修正ゲームはどの世代のソフトウェア エンジニアも悩ませており、未解決の謎のままです。

REEのセキュリティ問題が顕在化する中、GP（Global Platform）は2010年7月にTEE（Trusted ExecutionEnvironment）の概念を提案し、関連する技術標準を次々と策定してきました。TEEは、REEと共存しながら互いに分離された実行環境であり、REEよりもセキュリティレベルが高く、内部コードやデータの機密性や完全性を確保できます。キーの検証に合格すると、Rich OS から独立した小規模なオペレーティング システムが内部に組み込まれ、デジタル著作権保護、指紋認証、モバイル決済など、セキュリティとプライバシーに対する要求が高い信頼できるアプリケーションを実行できます。これにより、ソフトウェアの使用が回避されます。 REE からの脆弱性攻撃。

業界は現在、さまざまな命令セット アーキテクチャに対して、ARM の TrustZone、Intel の SGX (Software Guard Extensions)、AMD の PSP (Platform Security Processor) など、対応する TEE ソリューションを提案しています。近年、RISC-V命令セットの精力的な開発に伴い、Hex Five SecurityのMultiZone Securityソリューション、カリフォルニア大学バークレー校のKeystone Enclaveソリューション、上海交通大学のXia教授のチームが提案したPenglai Enclaveソリューションなどが登場しています。次々に出てきました。

1.2 PMP と IOPMP

TEE はソフトウェアとハ​​ードウェアの共同設計を代表するもので、その核心はハードウェア セキュリティ モジュールとソフトウェア ドライバー構成を使用してコードとデータの分離を実現することです。分離！分離！大事なことは3回言わないといけない！RISC-V TEE ソリューションで最も重要な分離ユニットは、MMU (メモリ管理ユニット)、PMP (物理メモリ保護)、sPMP (S モード PMP)、および ePMP (拡張 PMP) です。

暖かい注意: 上記の固有名詞について漠然とした概念を持っている読者は、このコラムで Xuantie C910 マイクロアーキテクチャの研究 (13) - メモリ管理ユニット、RISC-V 特権仕様[2]、RISC-V SPMP 仕様[3]、およびRISC-V Smepmp 仕様[4]。

このうち、MMU メモリ管理ユニットは、仮想アドレスから物理アドレスへの変換タスクを主に担当しており、メモリ仮想化技術により、プロセスが使用できるアドレス空間の範囲を拡大できるだけでなく、異なるユーザー プロセス間の動作も実現できます。システム間のメモリ分離 (S モード)、PMP 物理メモリ保護ユニットは、主に RISC-V HART のメモリ アクセス許可をチェックして、異なるオペレーティング システム間および M-Mode 間の分離を実現します。モードと S/U モード; sPMP ユニットは、MMU 機能をサポートしない IoT 組み込みシナリオを対象としています。システムはアドレス指定に物理アドレスを直接使用するため、MMU ユニットのメモリ アクセス許可を制限するには、MMU ユニットを置き換える sPMP が必要です。 S/U モード分離を実現する U モードと S モード。ePMP ユニットは RISC-V HART 内のジグソーパズルの最後のピースであり、PMP での過剰な M モード メモリ アクセス許可の問題を解決するために使用されます。 mseccfg レジスタを追加することで PMPCFG.L ビットの機能を拡張し、M モードおよび S/U モードのメモリ アクセス許可を特別にチェックして、RISC-V プロセッサ コア全体のセキュリティを確保します。

MMU、PMP、および ePMP に基づいて、チップ サプライヤーはアプリケーション レベルの TEE ソリューションをカスタマイズでき、sPMP、PMP、および ePMP に基づいて組み込みレベルのソリューションを設計して、ほとんどのセキュリティ ビジネス ニーズを満たすことができます。しかし、慎重な読者であれば、上記の 4 種類の絶縁ユニットが RISC-V プロセッサ コア用に設計されていることはすぐにわかります。SoC チップ システム全体を見ると、RISC-V プロセッサ コアに加えて、RISC を含まない XPU もいくつかあります。 -Vコア（GPU、NPU、TPUなど）、HAC（ハードウェアアクセラレータ）、NIC（ネットワークインターフェイスカード）などのメモリアクセス機能を備えた周辺ユニットなどのセキュリティは保証されていますか？

答えは明らかに「ノー」です！DMA (Direct Memory Access Unit) を例に挙げると、その機能はシステム内のデータ転送の効率を向上させることですが、PMP 機能のような保護ユニットがないため、DMA は実際にはシステム全体に対するアクセス権を持ちます。物理メモリ空間、これが SoC システムであり、セキュリティの脆弱性が存在する場所です。ハッカーがチップ内の DMA 機能を持つ周辺機器を乗っ取った場合、ユーザーの認証キー、アカウントのパスワード、Face ID などの機密データを権限制限なしで簡単に取得でき、計り知れない損失が発生します。PMP の以前の設計経験を参考にして、IOPMP (入出力物理メモリ保護) の概念が生まれました。このセキュリティ モジュールは、ルールをチェックするために M モードの最高のセキュリティ権限を持つ Secure Monitor によって構成され、特に次の目的に使用されます。制御 DMA 機能またはバス マスター ポートを備えたペリフェラルのメモリ アクセス動作は、SoC レベルでチップ システム全体のセキュリティ保護を提供します。

2. 用語

IOPMP のモデル構造と設計スキームを正式に紹介する前に、読者がその原理をよりよく理解できるように、最初にいくつかの基本概念を定義する必要があります。この記事の残りの部分では、これらの専門用語は説明なしに直接引用されます。

2.1 トランザクション

トランザクションの正確な定義は ARM の AXI 仕様 [6] に記載されており、ここで説明する AXI トランザクションとは、リクエストを送信するために AXI Manager によって完了する必要がある一連のバス操作を指します。

AXI Manager が AXI スレーブをターゲットとして AXI オペレーションを開始すると、次のようになります。 AXI バス上で必要なオペレーションの完全なセットが AXI トランザクションを形成します。

トランザクションには、データの読み書きを担当するRead/Writeトランザクション、キャッシュ情報の維持を担当するCMOトランザクション、データの一貫性維持を担当するSnoopトランザクションなど、多くのトランザクションタイプがあります。バスプロトコルごとに、それらの分類と定義も異なります。とても違います。異なるシステムバスの伝送ビット幅とバースト長の違いを考慮して、1 つのトランザクションを複数のトランザクションに分割したり、複数のトランザクションをマージしたりすることもできます。しかし、何はともあれ、トランザクションの特定の意味を拡張して、バス マスターがバス スレーブにリクエストを送信する完全なアクションをトランザクションと呼ぶことができます。

IOPMPの検査対象は実際にはトランザクションであり、バスマスターから送信されるすべてのトランザクションをインターセプトし、トランザクションに含まれるリクエストの種類、アドレス情報、データビット幅などを用いてアドレスのアクセス範囲やアクセスを確認する必要があります。 IOPMP エントリで指定された法的トランザクションのみを満たすものだけがバス スレーブに転送され、その後のデータ送信アクションは引き続き完了します。逆に、テーブルエントリ要件に準拠しない不正トランザクションは IOPMP によって無視されるか、IOPMP がバス マスターへの偽のバス応答信号を偽造するため、バス スレーブは不正トランザクションの発生にほとんど気づきません。

2.2 ソース識別 (SID)

RISC-V IOPMP 仕様 [7] の説明によると、ソース ID (SID) は、単一のバス マスター、または同じアクセス権を持つバス マスターのグループの一意の ID 番号を指します。

Source-ID (略して SID) は、同じ権限を持つバス マスターまたはバス マスターのグループを識別するための一意の ID です。

ただし、DMA デバイスなどの複数の伝送チャネルを持つバス マスターの場合、チャネル間の権限が一致しない場合、チャネルごとに排他的な SID 番号を設定する必要があることに注意してください。また、複数の権限レベルを持つ XPU の場合は、 U/S/H/M モード間の権限は異なるため、SID 番号は特権モードごとに個別に設定する必要があります。したがって、著者は、SID のより正確な意味は、各バス デバイスのメモリ アクセス許可の種類であるべきであると考えています。つまり、異なる SID 間ではメモリ アクセス範囲と操作許可が異なり、同じ許可を持つデバイスは SID を共有できます。ハードウェアのオーバーヘッドを節約します。

バス マスターによって送信されたトランザクションに SID 情報を追加することにより、IOPMP はトランザクション リクエストのソースを識別し、ルール エントリに基づいて対象のアクセス許可チェックを実行できます。情報を確認すると、SiFive と NVIDIA の両方が SID を参照するのに World ID (WID) を使用していることに気づく人もいることに注意してください。この 2 つはまったく異なります。SiFive の WID は各プロセスの許可 ID を指しますが、NVIDIA はWID の意味は上記の SID と完全に一致しており、両方とも各マスターの許可 ID を参照するために使用されます。

2.3 メモリドメイン (MD)

同様に、RISC-V IOPMP 仕様の説明によれば、メモリ ドメインは特定の機能を持つメモリ領域のグループを指します。NICを例にとると、内部には送信キュー、受信キュー、制御レジスタファイルの3つのメモリ領域(Region)があり、これら3つの領域を組み合わせたものをMDと呼びます。ネットワーク カード上で特定のバス マスターの操作権限を定義する必要がある場合は、まずその SID をネットワーク カードの MD に関連付けてから、各リージョンの SID のアクセス権限を定義します。

メモリ ドメイン (略して MD) は、IOPMP 内の概念です。これは、特定の目的のためにメモリ領域のセットをグループ化するために使用され、ゼロからインデックスが付けられます。

メモリ ドメインの分割は、TEE ソリューションによって実装される SoC アーキテクチャと密接に関連しています。たとえば、DDR メモリは単一の MD として使用することも、複数の MD に再分割することもできます。具体的な設定はプラットフォームによって異なります。区別するために、各 MD には個別のメモリ ドメイン識別 (MDID または DID) マークも必要です。なお、MDID番号が小さいほどルールチェックの優先順位が高くなるため、セキュリティレベルの高いメモリドメインやアクセス頻度の高いメモリドメインには小さいMDID番号を割り当てることをお勧めします。

メモリ ドメインの機能は、MD 粒度でルール エントリを再利用することです。複数の SID を指定した MD に関連付けることにより、SID ごとに追加の個別のチェックを設定しなくても、MD 内の既存のチェック ルールを再利用できます。SID と MD 間のマッピング関係を変更するだけで、ユーザーがバス マスターのメモリ アクセス許可をバッチで変更できるようになり、ソフトウェアとハ​​ードウェアのコラボレーションの効率が向上します。

2.4 IOPMP エントリ

IOPMP エントリは IOPMP 全体の中核であり、トランザクション検査に関連するルールを定義します。PMP に精通している読者は、PMP が PMPCFG レジスタのチェック ルールのロック ビット (L)、アドレス マッチング モード ビット (A)、実行許可ビット (X)、書き込み許可ビット (W)、および読み取り許可ビット® を定義していることを知っているはずです。そして、特定の形式の物理アドレス情報が PMPADDR レジスタに定義されます。IOPMP Entry は、PMPCFG および PMPADDR レジスタの設計概念を拡張し、ロック ビット、読み取りおよび書き込み実行許可、アドレス マッチング モード、アドレス情報ビットも備えており、静的 IOPMP Entry テクノロジなどの特定の最適化ソリューション向けに適切に拡張されています。

IOPMP Entry のアドレス マッチング モードとアドレス情報に基づいて、リージョンの物理アドレス範囲を推測できます。1 つの MD 内に複数のリージョンがあることを考慮すると、当然、複数の IOPMP エントリが存在します。トランザクション チェック プロセス中に、MD は、それが保持する SID に基づいて決定され、MD 内のすべてのエントリと比較される必要があります。トランザクションによってアクセスされたバイトのみが、エントリで指定された物理アドレス範囲内にあることが判明します。メモリアクセスタイプはEntryに準拠しており、指定された読み書き実行権限がある場合のみ正当なトランザクションとみなされ、それ以外の場合は不正なトランザクションとして処理されます（デフォルトはブラックリスト機構）。なお、IOPMP エントリには静的な優先度という概念があり、エントリのインデックス値 (Index) が低いほど優先度が高くなります。このように、トランザクションのメモリアクセス範囲が複数の IOPMP エントリに一致する場合、優先度のみが優先されます。最高レベルの IOPMP Entry チェック結果が優先されます。

3. IOPMP の構造フレームワークの紹介

前の章を読んだ読者は、IOPMP の全体的な機能をより抽象的に理解できるはずです。IOPMP は、バス マスターの SID を使用してトランザクション チェックを実行します。内部的に各 MD に対応する IOPMP エントリ ルール テーブル エントリを定義し、MD Itは、TEE スキーム設計で事前に分割されています。次に、この章では、読者が IOPMP のハードウェア モデルの概念を具体化できるように、IOPMP の構成構造とルール チェック プロセスについて詳しく説明します。

図 3 は、NVIDIA の IOPMP 提案の例を示しています。合計 3 つのバス ポートがあることがわかります。スレーブ ポートの 1 つは制御チャネルを形成し、特にルールの構成を確認し、さまざまな内部マッピング検索を変更するために使用されます。レジスタまたは SRAM の読み取りと書き込み、テーブルとルール テーブル、別のマスター ポートとスレーブ ポートのセットがデータ パスを形成し、特にバス マスターとバス スレーブ間のトランザクションをインターセプトし、ルール チェック メカニズムを通じてペリフェラルのメモリ アクセス動作を規制するために使用されます。 。もちろん、これは IOPMP ポート設計の単純な例にすぎません. IOPMP ポートの数が 3 つ以上であれば、SoC システム プラットフォームへの統合が実現できます. リーダーは、開発中にそれをマルチチャネル構造に適切に拡張できます。しかし、これはハードウェア リソースが 2 倍になることを意味し、トレードオフが必要になります (具体的な設計については [9] を参照)。

図 4 は Andes によって提案された IOPMP 組織構造の例を示しており、主に SRCMD Table、MDCFG Table、IOPMP Entry Array の 3 つの部分から構成されており、これら 3 つのサブモジュールの機能を以下に紹介します。

3.1 SRCMD テーブル

SRCMD テーブルは SRCMD レジスタ ファイルで構成され、SID と MD の間のマッピング関係を記録する役割を果たします。IOPMP 仕様で定義されている SRCMD レジスタのビット幅は 64 ビットで、最上位ビットは SRCMD レジスタ全体の書き込み許可を制御するロックビット (SRCMD.L) で、残りの 63 ビット (SRCMD.MD) ) はビットマップ形式で表現され、SID と MD のマッピング ベクトルになります。SRCMDx のビット y が「1」の場合、MDID y にアクセスするときに、SID x が MDID y のすべてのチェック ルールに合格する必要があることを意味します。

3.2 MDCFG テーブル

MDCFG テーブルは MDCFG レジスタ ファイルで構成され、MD に対応する IOPMP エントリ インデックス範囲を記録する役割を果たします。IOPMP 仕様で定義されている MDCFG レジスタのビット幅は 32 ビットで、その下位 16 ビット (MDCFG.T) は、MD に関連する IOPMP エントリのインデックスの上限を表すと同時に、 MD 番号に隣接する次の MD IOPMP エントリ アドレスの下限、このアドレス指定方法は TOR (Top of Range) モードと呼ばれます。MDID が y の場合、対応する IOPMP Entry アドレス範囲は MDy-1CFG.T ～ MDyCFG.T です。具体的には、MDID 0 の下限は 0 です。

3.3 IOPMP エントリ配列

IOPMP エントリ アレイは、その名前が示すように、IOPMP エントリで構成され、トランザクション ルール チェックのための物理アドレス範囲と対応するアクセス権を記録する役割を果たします。IOPMP エントリの数が多いため、SRAM を使用して実装することをお勧めします。

3.4 取引検査の基本的な流れ

IOPMP のトランザクション検査は主に上記 3 つのテーブルに焦点を当てており、具体的なプロセスは次のように説明されます。

• ① データパスのスレーブポートが緊急に確認が必要なトランザクションを受信する

• ② トランザクション内の SID 番号を解析し、S​​RCMD テーブルをクエリし、MD マッピング ベクトルを取得します。

• ③ ビットマップレコードの MDID に従って MDCFG テーブルを検索し、MD に対応する IOPMP Entry 範囲を取得します。

• ④ インデックスアドレスに基づいて IOPMP Entry Table を検索し、アドレス範囲の一致とアクセス許可の比較を実行します。

• ⑤ アドレスが正常に一致するか、トラバースが終了するまで、手順③と④を繰り返して、SID に関連するすべての MD をトラバースします。

• ⑥ チェック結果に応じて対応する処理を行い、正当なトランザクションであればデータパスのMasterポートを制御してトランザクションを転送し、不正なトランザクションであればトランザクションをシンクまたは結果を偽造して不正なトランザクションを記録する情報を取得したり、バスエラー信号に応答したり、割り込みをトリガーしたりできます。

IOPMP の 4 つまたは 5 つのモデル バリアント

IOPMP の基本構造は主に 3 種類のテーブルで構成されており、テーブルルックアップで消費される遅延はクリティカル パスに直接影響し、これらのテーブルの実装には多くのハードウェア リソースが消費されるため、制限が厳しいアプリケーションに適しています。この分野では、インデックス要件を満たすように IOPMP モデルを適切に調整する必要があるため、次の 5 つの IOPMP モデルが生まれました。

4.1 フルモデル

フルモデルは、3 つのテーブルのすべての機能を完全に実装します。トランザクション ルール チェックの遅延が最も長く、ハードウェア オーバーヘッドが最も大きくなります。ただし、大量の IOPMP チェック ルール エントリを柔軟に管理できます。異なる間で MD を共有できます。 SID、異なるMDの共有が可能で、対応するIOPMPエントリ数も自由に設定できるため、複雑な大規模SoCシステムへの適用に適しています。

4.2 分離モデル

分離モデルは SRCMD テーブルを簡素化します。完全なモデルで多対多のマッピング スキームを使用する代わりに、SID は同じ MDID 番号を持つ MD とのマッピング関係を直接形成します。これは、SID x が次の方法でのみ MD にアクセスできることを意味します。 MDID x. . このモデルは、SRCMD Tableの実装領域を節約し、トランザクションルールチェックの総遅延を削減できます。SID と MD が順番に対応すると、MD の再利用の利点が失われることに注意してください。複数の SID が MD を共有する必要がある場合、対応する IOPMP エントリ ルールを追加で設定することしかできませんが、この部分のオーバーヘッドは明らかに少なくなります。 SRCMD テーブル自体よりも。

4.3 Rapid-K モデル

fast-K モデルは MDCFG テーブルを簡素化します。各 MD に対応する IOPMP エントリの数は K に固定されます。ここでの K は通常 2 の指数形式であるため、各 MD に対応する IOPMP はシフターを使用して計算できます。エントリのインデックスMDCFG レジスタを検索せずにアドレス範囲を設定します。IOPMP 仕様では、異なるモデル間でセマンティックの一貫性を維持するために、ユーザーが IOPMP モジュールの構成情報を学習できるように、Rapid-K モデルでも MDCFG テーブルを実装し、対応する MDCFG.T ビットを設定する必要があることを特に強調しています。このモデルにより、トランザクション ルール チェックの全体的な待ち時間を短縮できます。ただし、著者は、よりカスタマイズされた TEE ソリューションの設計では、ハードウェア領域のオーバーヘッドを節約するために MDCFG テーブルを省略することが良い選択である可能性があると考えています。

4.4 ダイナミックKモデル

fast-K モデルと比較した場合、ダイナミック K モデルとダイナミック K モデルの唯一の違いは、K 値が動的に構成可能であることです。これにより、IOPMP エントリ エントリをより柔軟に割り当て、IOPMP エントリ アレイのスペース使用率が向上します。 。また、モデル セマンティクスの一貫性を維持するために、ユーザーが IOPMP モジュールの構成情報を学習できるように、MDCFG.T ビットは K 値の変更を反映する必要があるため、このモデルはトランザクション ルール チェックの総遅延を削減できます。しかし、著者は依然として、CFG レジスタを特別に設定して IOPMP のモデル変更を反映できると考えており、それによってハードウェア領域のオーバーヘッドを節約するために MDCFG テーブルの必要性が排除されます。

4.5 Compact-Kモデル

streamlined-K モデルは、分離モデルと fast-K モデルの利点を組み合わせ、SRCMD テーブルと MDCFG テーブルの両方を簡素化します。各 SID は固定数の IOPMP エントリに直接対応します。合計のトランザクション ルール チェック遅延は短いです。ハードウェアはオーバーヘッドが低く、リソースとコストに厳しい制限があるアプリケーション シナリオに適しています。

5. IOPMPモジュールのトポロジー的組織構造

IOPMP モジュールの機能と構造をより明確に理解した後、それを既存の SoC システムに統合してみることができます。バストポロジの規則性と高い拡張性により、IOPMP モジュールの統合方法も柔軟かつ多様になり、SoC システムの具体的な実装プラットフォームによって異なりますが、一般的に次の 4 つに分類できます。前述のトポロジカルな組織化手法。

5.1 ソースの強制

Source Enforcement ソリューションとは、バスと、バス マスター ポートまたは DMA 機能を備えたマスター デバイス (トランザクション送信側に近い側) との間に IOPMP を配置することを指します。RISC-V コアを除く残りのマスター デバイスには、IOPMP が装備されている必要があります。例 スキームを図 9 に示します。この配置モードは比較的単純です。各マスター デバイスの SID 番号と同じ番号で IOPMP ユニットを構成するだけで済みます。また、IOPMP はトランザクションの送信ポートに直接接続されているため、識別するための SID 番号は必要ありません。内部 SRCMD テーブルと MDCFG テーブルは省略され、IOPMP エントリ アレイのみを実装する必要があるため、トランザクション ルール チェックの速度が向上し、IOPMP 設計の難易度が大幅に軽減されます。

図 9 IOPMP の Source Enforcement ソリューションの例 ([9] から抜粋)

また、このソリューションのもう1つの利点は、後述するDestination Enforcementソリューションのような集中検査を必要とせず、すべてのマスターデバイスのトランザクションを分散並列で検査できるため、IOPMPユニットの統合によって引き起こされる問題を軽減できることです。パフォーマンスの損失。しかし、このソリューションの致命的な欠陥は、ソースエンドにある各 IOPMP をマスターデバイス間で共有できず、検査ルールの再利用が実現できず、共通の冗長現象が存在することです。さらに重要なのは、単一 IOPMP のハードウェア オーバーヘッドは減少しましたが、マスター デバイスの数が多すぎると、実装する必要がある IOPMP ユニットの数が急増し、TCO の大幅な増加を引き起こすことです。

図 10 は、Xuantie C シリーズ プロセッサの VirtualZone セキュリティ ソリューションを示しています。この例では、Source Enforcement 戦略を使用して IOPMP ユニットを統合しています。GPU と XPU には独自の IOPMP ユニットがあり、DMA 機能を備えた 2 つの暗号化デバイスが共有 IOPMP ユニットを使用して、IOPMP ユニットを削減します。導入コスト。

5.2 宛先の強制

ソース強制スキームとは対照的に、デスティネーション強制スキームは、バスとバス スレーブ ポートを備えたスレーブ デバイスの間、つまりトランザクション レシーバーに近い側に IOPMP を配置します。スキームの例を図 11 に示します。スレーブ デバイスはトランザクションのソースを識別できないため、区別するために各マスター デバイスに特定の SID 番号を追加する必要があります。

このソリューションの利点は、トランザクション検査作業がより集中化され、ユーザーが IOPMP ユニットを集中管理するのに便利であることです。SID と MD を合理的に分割することで、MD が異なる SID で共有されるという特徴を最大限に活用でき、IOPMP Entry の多重度が向上し、ハードウェアのオーバーヘッドが節約されます。ただし、前述したように、Destination Enforcement ソリューションでは宛先での集中チェックが必要となるため、複数のマスター デバイスがスレーブ デバイスに同時にアクセスした場合、トランザクション チェックのシリアル化プロセスにより、調停優先度が最も低いマスター デバイスが削除されます。長時間使用すると、SoC システム全体のパフォーマンスに大きな影響を与えます。

図 12 は SiFive WorldGuard セキュリティ ソリューションを示しており、WorldGuard と IOPMP は実装方法が根本的に異なりますが、実装目的は一貫しているため、一定の参考値もあります。この例では、宛先強制戦略を使用して、WG PMP ユニットと WG フィルター ユニットの統合を実現しています。WorldGuard 仕様に関するコミュニティのディスカッションでは、驚くべきことに、SiFive がかつてソース強制ソリューションを放棄し、顧客が好む宛先強制の使用を選択したこともわかります。の計画です。

多くの顧客が WG の QoS アプローチ (スレーブ側でトランザクションをチェックする) を好むため、IOPMP アプローチ (つまり、マスター側にフィルターを配置する) は拒否しました。参考文献の抜粋[14]

5.3 カスケード IOPMP

スタック IOPMP は、SoC システム内の IOPMP のカスケードを指します。この現象は、たとえば、ソースと宛先の強制ソリューションを混合したり、複数の SoC サブシステムを IOPMP ユニットと統合したりすることによって発生します。より具体的には、図 11 の PMP と IOPMP の間にはカスケード現象もあります。つまり、RISC-V HART トランザクションが PMP ルールによってチェックされた後、再度 IOPMP によってチェックされます。RISC-V コアが Smepmp セキュリティ拡張機能を実装している場合、送信するトランザクションは PMP によるチェックの後、安全で信頼できるものになります。2 番目のチェックは必然的に冗長に見えます。トランザクション リクエストの速度が低下するだけでなく、 SoC システム全体にも影響が及び、パフォーマンスも低下します。

同様に、カスケード IOPMP にも冗長性のチェックの問題がある可能性があるため、カスケード IOPMP トポロジでは、Pass-One チェック原則に従う必要があり、つまり、各トランザクションがその要求パス上で最大 1 回チェックされるようにする必要があります。この目的のために、特定のバイパス戦略を設定できます。たとえば、最初にすべての IOPMP ユニットが SID 0 のトランザクションをバイパスすることを規定し、次に IOPMP ユニットが検査後に正当であると判断されたすべてのトランザクションの SID 値を変更することを規定します。を 0 にすると、Pass-One の原則が達成されます。

スタック IOPMP ソリューションの本来の目的は、単一 IOPMP 検査のカバレッジが不十分であるという問題を解決することです。SRCMD テーブルの構造を振り返ると、仕様で指定されている MD の最大数が 63 であることがわかります。 SoC システム内の MD の数がこのしきい値を超えると、カスケード接続することができます。 ホワイトリスト チェック メカニズムを採用する最後のレベルの IOPMP を除き、それより前の残りの IOPMP ユニットはブラックリスト チェック メカニズムを採用し、それによってすべての MD ルール チェックをカバーします。さらに、Pass-One 原則に従うことを前提として、このカスケード ソリューションはクリティカル パス遅延への影響を最小限に抑えます。

5.4 IOMMU と IOPMP

IOMMU (Input/Output Memory Management Unit) は、DMA 機能を持つ IO デバイスとシステム メモリの間に位置するメモリ管理ユニットで、主に DMA アドレスのリマッピングと MSI 割り込みのリダイレクトを担当します。仮想マシン (仮想マシン) が有効になっていないシステムでは、IOMMU により、オペレーティング システムが仮想アドレス IOVA (I/O 仮想アドレス) を使用して DMA を制御できるようになり、DMA 読み取りおよび書き込み領域が特権メモリ領域から分離され、マルウェアや誤動作が防止されます。 IO デバイス ドライバーは、DMA を使用して特権メモリ領域のデータを改ざんします。また、IOVA を使用すると、デバイスが広範囲の連続した仮想アドレス空間にアクセスできるようになり、物理アドレス空間の断片化の影響を回避できます。たとえば、32 ビット デバイスは、IOMMU の支援を受けて 64 ビットの物理空間にアクセスできます。仮想化が有効になっているシステムでは、IOMMU は、GPA (ゲスト物理アドレス) から PA への単一レベルのアドレス変換と、IOVA から GPA から PA への第 2 レベルのアドレス変換をサポートすることにより、システムが IO デバイスの透過的な送信を実現できるようにします。仮想化テクノロジ実装のソフトウェア オーバーヘッド。

図 13 は、IO Bridge を例として、IOMMU、PMA Checker (物理メモリ属性チェッカー)、および IOPMP の組織構造の関係を説明しています。IO デバイスがメモリ アクセス リクエストを開始すると、IOMMU はまずアクセスする仮想アドレスを物理アドレスに変換する必要があります。その後、IO ブリッジがバス プロトコル変換を実行し、トランザクション リクエストを開始します。その後、PMA チェッカーが属性をチェックします。 IOPMP は、アクセスされる物理アドレスの範囲と許可が設定されたルール要件を満たしているかどうかを最終的にチェックする責任を負い、チェックに合格した後にのみ、メモリ アクセス リクエストが正式に IOPMP に送信されます。バス インターコネクトは調停と結果の返信を待ちます。IOMMU 自体も、コンテキスト情報、変換ルールとページ テーブル情報、アクセス要求キューなどの取得などのメモリ アクセス要求を送信するため、各 IOMMU も IOPMP 用に個別の SID 番号で構成する必要があることに注意してください。メモリアクセス許可チェックを実行します。

6. IOPMP の設計ガイド

この時点で、IOPMP の話は終わりに近づいていますが、読者は次の 3 つの質問に対して明確な答えを持っていると思います: 「IOPMP とは何ですか? IOPMP と PMP の違いは何ですか? TEE にはなぜ IOPMP が必要ですか?」この記事の一部で、IOPMP に関する情報を共有します。デザインのアイデアが、読者の思考にインスピレーションを与えることができれば幸いです。

6.1 IOPMP のパフォーマンス最適化手法

• ① グローバル IOPMP エントリ: グローバル チェック ルール エントリに基づくトランザクション チェックは、通常のトランザクション チェックと並行して実行され、グローバル テーブル エントリでトランザクションが正常に照合された場合、定期チェック プロセスを事前に終了することができ、大幅なトランザクション チェックを実行します。ルール テーブル エントリの検索時間を節約し、メモリ アクセス パスの遅延を短縮します。

• ② 静的 IOPMP エントリ: 一部のペリフェラルの MMIO レジスタやバッファなどのメモリ空間の物理アドレスと、対応する読み取りおよび書き込み権限は比較的固定されており、静的チェック ルール エントリを使用すると、プログラマブルなアドレス デコードを節約できるだけでなく、ハードウェアのオーバーヘッドも削減できます。これにより、IOPMP ドライバー構成チェックルールのタスクの負担が軽減され、ユーザーの構成ミスの可能性が減ります。

• ③トランザクションチェックの並列性向上：IOPMP Channelのチャネル数、MDのトラバース並列性、IOPMP Entryコンパレータ数などを増やすことで、トランザクションチェックの並列性を向上させることができます。パフォーマンスは確かに実現可能ですが、合理的である必要があり、設計の最適点を見つけるにはトレードオフが必要です。

• ④ 投機的実行: バス応答チャネルの信号をインターセプトすることにより、IOPMP は投機的にトランザクションをバス スレーブに転送し、トランザクション チェック プロセスを開始できます。応答データを受信し、ルール チェックが完了した後、IOPMP は結果を調べ、選択することができます。応答信号を転送、偽造、またはドロップします。投機的実行テクノロジは、トランザクション ルールのチェック時間を隠すことにより、IOPMP のパフォーマンスを大幅に向上させることができます。

6.2 IOPMP の設計の難しさ

• ① アトミック性の問題: IOPMP 検査ルールの変更には複数のトランザクションが関与する可能性があり、たとえば、MD の作成および破棄操作は、複数の SRCMD レジスタと複数の IOPMP Entry ルール エントリに影響を与えます。チェック ルールを変更するプロセスで、IOPMP データ パスがまだトランザクション ルールをチェックしている場合は、典型的な TOCTOU (Time-of-Check Time-of-Use) 問題が発生します。つまり、チェックは、古いルールとは何ですか？それとも、変更されていない新しいルールに従うべきでしょうか? これにより、新たなセキュリティ問題が発生する可能性があります。

• ② デッドロック問題: アトミック性の問題を解決するために IOPMP データ パスをブロックする方法を使用すると、すべての IOPMP 制御パス トランザクション検査を担当する IOPMP が自己ロックします。追加の制御レジスタが追加された場合は、ストールのみを選択します。ルールのあるもの 関連する SID が変更されると、バス マスターはルールの設定中にマッピング関係を持つ MD を変更する必要があるため、再びデッドロック状態になります。

• ③ その他の質問: IOPMP を有効にし、IOPMP をリセットし、その動作状態を動的に切り替えるにはどうすればよいですか? IOPMP はこれらの制御信号にいつ応答する必要がありますか? バス マスターのリクエスト信号とバス スレーブの応答信号をインターセプトするにはどうすればよいですか? デッドロック メカニズムを使用してルール テーブル エントリのセキュリティを保護するにはどうすればよいですか? これらの問題は、読者が設計プロセス中に深く検討する価値があります。

7. まとめ

RISC-V IOPMP 仕様の開発はまだ本格的に行われており、IOPMP タスク グループは、今年の第 3 四半期に仕様設計を完了し、関連計画を凍結する予定です。しかし、学術界や産業界における IOPMP の設計検討は実際には非常に早くから始まり、Saifang Technology は [9] で Rapid-1 タイプの IOPMP モデルを実装し、チェック ルールを変更するときに遭遇するアトミック操作の問題を詳細に説明し、理論的に分析しました。 IOPMP によって引き起こされる SoC システムのパフォーマンス損失; Alibaba Cloud は [12] で Xuantie RISC-V プロセッサ用の VirtualZone セキュリティ ソリューションを提案し、IOPMP モジュールの 3 つの組織化方法を列挙しました; 広東理工大学は [12] で Rapid-K タイプの IOPMP モデルを実装しました16] を発表し、Xuantie E902 プロセッサをベースにした軽量 DITES セキュリティ ソリューション プロトタイプを構築しました。SiFive の WorldGuard ソリューションは IOPMP ソリューションに反しますが、RISC-V TEE ソリューションの進歩が知恵を提供し続けています。私たちは、企業や各界のリーダーのリーダーシップの下で、RISC-V TEE セキュリティ ソリューションが徐々に改善され、RISC-V プロセッサ コアと SoC チップ システム全体を保護するために実装されると信じています。

8. 参考文献

声明: この記事で引用されている写真および一部のデザインコンセプトはすべて公的文献から引用したものであり、関連する出典が示されていますが、侵害がある場合は、このコラムの管理者または著者本人にご連絡ください。

【1】「セキュアブートの簡単な分析」 https://bbs.kanxue.com/thread-260399.htm

【2】『RISC-V 命令セットマニュアル、ボリューム II: 特権アーキテクチャ、文書バージョン 20211203』、編集者 Andrew Waterman、Krste Asanovic、John Hauser、RISC-V International、2021 年 12 月。

【3】《RISC-V SPMP仕様》 https://github.com/riscv/riscv-spmp/blob/main/rv-spmp-spec.pdf

【4】《RISC-V Smepmp仕様》 https://github.com/riscv/riscv-tee/blob/main/Smepmp/Smepmp.pdf

【5】《Andes 強化型 IOPMP による安全なプラットフォームの構築》 https://www.slideshare.net/RISC-VFoundation1/andes-building-a-secure-platform-with-the-enhanced-iopmp

【6】《AMBA AXIおよびACEプロトコル仕様》 https://developer.arm.com/documentation/ihi0022/hc/?lang=ja

【7】《RISC-V IOPMP仕様》 https://github.com/riscv-admin/iopmp/blob/main/specation/riscv_iopmp_specation.pdf

【8】《IOPMP提案0.5.1》 https://lists.riscv.org/g/tech-tee/topic/file_iopmp_proposal_0p5_pptx/80135860

【9】Ng JH、Ang CH、Law H C. RISC-V システム向け IO 物理メモリ保護の実現[C]//2022 IEEE 15th International Symposium on Embedded Multicore/Many-core Systems-on-Chip (MCSoC) 。IEEE、2022: 375-380。

【10】《RISC-V IOPMPの中身》 https://riscvsecurityforum2021.sched.com/event/iWe4/lightning-talk-what-in-risc-v-iopmp-shan-chyun-ku-andes-technology

【11】《IOPMPモデル》 https://lists.riscv.org/g/tech-tee/topic/iopmp_models/87723547

【12】《XuanTie VirtualZone: RISC-Vベースのセキュリティ拡張機能》 https://riscv.org/blog/2022/04/xuantie-virtualzone-risc-v-based-security-extensions-xuan-jian-alibaba/

【13】https://www.sifive.com/technology/shield-soc-security

【14】https://lists.riscv.org/g/tech-tee/message/312

【15】《RISC-V IOMMU仕様》 https://github.com/riscv-non-isa/riscv-iommu/blob/main/riscv-iommu.pdf

【16】Chen Y、Chen H、Chen S 他 DITES: RISC-V[J] ベースの軽量で柔軟なデュアルコアの絶縁型信頼できる実行 SoC。センサー、2022、22(16): 5981。

コンテンツの由来

RISC-V TEE の SoC レベルのセキュリティ モジュール - IOPMP の簡単な分析

RiscV について詳しくは、Tuzikさんのコラムがとても参考になります。！！