問題タブ [trust-zone]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
arm - FIQ 発生時に el3 から nwd 32 ビット プロセスに返されると、セグメンテーション フォールトが発生する
トラストゾーンエミュレーションでqemuを実行しています。64 ビット Linux は Normal world (NWD) EL1 で実行され、一部の独自コードは EL3 および Secure World (SWD) EL1 で実行されます。また、割り込みの構成は次のとおりです。1) FIQ は SWD に割り当てられます。2) IRQ は NWD に割り当てられます。
また、nwd が FIQ によって中断される可能性のある 3 つのケースがあります。
FIQ が発生すると、EL3 によってトラップされます。次に、NWD コンテキストが EL3 のコードによって保存され、FIQ のハンドラーが実行を開始します。el3 から NWD に戻った後、1)、2) ケースはすべて正常に動作します - 中断されたプロセスは引き続き動作します。しかし、ケース 3) で el3 から NWD に戻った後、中断されたプロセスに対してセグメンテーション フォールトが発生しました。また、これは el3 から NWD EL0 に戻る前の spsr_el3 レジスタの値 - 0x600f0010 - 正常に見えます。また、ケース3のEL3で保存および復元されたコンテキストをすでに比較しており、それも問題ないようです。これはqemuのバグのようです。何が問題なのか知っている人はいますか?
security - 悪意のあるソフトウェアが ARM TrustZone で SMC 例外を発生させないようにするものは何ですか?
ARM TrustZone について読んでいます。Normal World が Secure World からの関数を必要とする場合、SMC 例外を発生させて Secure World に転送することを読みました。私が理解できなかったのは、悪意のあるコードが SMC 例外を発生させないようにするものは何ですか? 無許可のソフトウェアがセキュア ワールドへの転送を引き起こす可能性がある場合、セキュア ワールドはどのように「安全」になるのでしょうか?
caching - TrustZone システムのセキュア DMA と非セキュア CPU の間でコヒーレンシの問題が発生する可能性があります
DMA と CPU 間の一貫性に関する問題に遭遇しました。これが単純化されたユースケースです。
Cortex A5 CPU は、非セキュア状態で非セキュア メモリに書き込みます。MMU は有効で、メモリ属性は通常、共有可能、キャッシュ可能です。したがって、データは、次の参考文献によると、いわゆる非セキュア キャッシュにある可能性があります。
[1] DDI0434B_cortex_a5_mpcore_r0p1_trm の「データ キャッシュ タグ データ フォーマット」
[2] アーティレス ノイズからの回答セキュア モードでセキュア/非セキュア メモリにアクセスするにはどうすればよいですか?
[3] http://atmel.force.com/support/servlet/fileField?id=0BEG000000002Urの 6 ページ目
DMA は、そのメモリ領域に対して安全なコヒーレント読み取りを発行します。DMA は ACP に接続されています。
SCU は、セキュアとしてタグ付けされたキャッシュのみをチェックしようとします。したがって、データは DDI0434B_cortex_a5_mpcore_r0p1_trm の「ACP 要求」に従ってメイン メモリから返されます。
DMA は古いデータを取得する可能性があります。
私の説明が正しければ、ここに私の 2 番目の質問があります。この問題を解決できるアクションはどれですか?
1) DMA 読み取りの前に明示的にキャッシュを消去する
2) メモリの属性を通常、共有可能、キャッシュ不可に変更します。
また、TRM は、「バス インターフェイス ユニットと SCU インターフェイス」の SCU インターフェイスに書き出される前に、キャッシュ エビクションまたはキャッシュ不可能な書き込みバーストからのデータを保持するために使用される書き込みバッファーがあると述べています。ただし、書き込みバッファーに関するこれ以上の情報は見つかりません。書き込みバッファには一貫性を確保するための魔法があると思いますか? 誰かが魔法を説明できるなら、私はとても感謝しています.
より多くの組み合わせを考慮して、このテーブルを自分で取得します。
最初の列は、CPU がメモリに書き込む状態を示します。
2 番目の列は、メモリが安全かどうかを示します。ここで「セキュア」とは、AxPROT[1] が High の場合に AXI によってアクセスが拒否されることを意味します。メモリ属性は通常、共有可能、キャッシュ可能です。
3 列目は、DMA が発行するアクセスの種類を示しています。アクセスは一貫しています。
4 番目の列は、何が起こるかを示します。
NG は、DMA が古いデータを取得する可能性があることを意味します。
NA は、アクセスが不可能であることを意味します。
OK は、DMA が CPU とコヒーレントであることを意味します。
ですよね?
Notlikethat's answer に従って、この部分を追加します。実際には悪夢かもしれません。しかし、私は理論的に何が起こるか知りたいです。
- 物理アドレス 0x10 が 2 つの仮想アドレス NS:0x110 と S:0x210 にマッピングされているとします。
- セキュア状態の CPU は、値 0x110 を NS:0x110 に書き込み、次に値 0x210 を S:0x210 に書き込みます。
つまり、両方が同時に L1 キャッシュにある可能性がありますよね? - 次に、DMA1 は PA 0x10 への安全な読み取りを行い、0x210 を取得する場合があります。DMA2 は、PA 0x10 に対して非セキュアな読み取りを行い、0x110 を取得する場合があります。
- その後、最終的にどちらが主記憶に残るかは予測不能です。
私の理解を確認または修正してください。どうもありがとうございます。