1.図に示すように、「画像の認証」プロセスは、SHA-512ハッシュ化の段階でハッシュ値を検証するのでしょうか？
2. ハッシュ値を設定した場合、BootROMはイメージの整合性を検証しますか？BootROMの検証に失敗した場合、リカバリーモードに入るのでしょうか？
上の図に示すように、イメージに署名するだけで暗号化しない場合、ブートROMの検証フローを通過できるでしょうか？さらに、oem_closeが有効になっている場合でも、ブートROM検証フローに入ることは可能でしょうか？
2. リカバリーブートヒューズを有効にする。
3. 私の目標は暗号化されていない画像を使うことです。ブートROMはイメージハッシュを計算し、検証する必要があります。ハッシュ検証が失敗した場合、ブートROMはリカバリブートフローに入り、LPSPI NORフラッシュからリカバリイメージを起動する必要があります。
下記に、お客様からの2つのご質問に対する回答を記載いたします。
1. 署名のみ(暗号化されていない)イメージがBootROM検証フローを通過できますか?はい。RT1180 AHABでは、署名(認証)がセキュアブートの必須部分であり、画像の真正性と整合性を確保しています。一方、暗号化(OTFAD/IEE)は独立した任意のアンチクローン機能であり、検証の前提条件ではありません。したがって、署名のみのイメージは通常どおり完全な AHAB 署名検証フローを通過します。これは、NXP の公式 SPSDK rt118x_secure_boot サンプルにおける標準的なアプローチでもあります。
2. oem_close (OEM_CLOSED) が有効になっている場合でも、検証フローは実行されますか？はい、そして本人確認が必須となります。
おすすめ: oem_closeを実行する前に、署名済みイメージをOEM_OPEN状態でプログラムし、ELEイベントなしで正常に起動することを確認すると、デバイスを閉じてください(SRKHはフュージョンされると不可逆的です)。部品のブリックを防ぐためです。
(参照:i.MX RT1180セキュリティリファレンスマニュアル。会社のアカウントを通じてNDAに署名した後、オンラインの営業担当者にリクエストを提出してください。)
こんにちは@yanyanwangさん
A1：はい。RT1180はAHABを2つの認証層で使用しています:
- 署名レイヤー：ECDSA（SHA-256 / SHA-384）は、コンテナヘッダーとイメージ配列エントリ（各イメージのハッシュを格納する）を検証します。
- ハッシュ層：ROMはロードされたイメージ本体のダイジェストを再計算し、イメージ配列エントリに格納されているハッシュと比較します。
図中のSHAハッシュ段階はまさにこの必須の整合性チェックであり、ハッシュ値を検証するものです。
A2: ROMは常にハッシュを計算・比較しますが、失敗が強制されるかどうかはデバイスのライフサイクルによって異なります。アウトオブファブのデフォルトはOpen構成で、認証は実行されますが、すべての認証エラーは無視され、画像は実行されます。デバイスをOEM_CLOSEDに移動して初めて 、ハッシュの不一致が起動をブロックします。
リカバリーモードに入るかどうかは、リカバリーブートヒューズの状態によって決まります。有効化されると、プライマリブート認証の失敗がリカバリーデバイスから再ロードおよび再認証が引き起こされます。有効化されていない場合、フローはシリアルダウンローダー/フェイタルモード/リセットループに移行します。
よろしくお願いします、
ギャビン
CM33イメージもCM7イメージも起動しなかった。しかし、コンテナヘッダーを確認したところ、CM33イメージしか存在しないことがわかりました。CM33イメージ自体は単独で使っても問題なく正常に起動できます。
CM7イメージが想定どおりに含まれなかった、あるいは処理されなかった理由、そしてCM7 ITCM ECC構成の欠如がブートROMによるCM7イメージの処理方法に影響を与えるかどうかを理解したいと考えています。
質問2：
8つのCM7イメージと1つのCM33イメージを1つのコンテナに統合した場合、ブートROMは起動プロセス中にどのような動作をしますか？
CM7コアは1つしかないのに、ブートROMはどのCM7イメージを起動するかをどのように判断するのでしょうか？もし8枚の画像エントリすべてがCM7の画像なら、Boot ROMは8枚すべての画像を読み込むのか、1枚だけを選択するのか、それとも選択はCM33アプリケーションに任せるのか?
Boot ROMは、同じコンテナ内の複数のCM7イメージエントリをどのように識別し、処理するのですか？どのCM7イメージを実行するかを決定するために使用される優先順位、イメージインデックス、コアID、ロードアドレス、エントリポイント、またはその他のメカニズムはありますか？
また、CM7 ITCM ECCが有効になっている場合と無効になっている場合における、ブートROMの正確な動作についても理解しておきたい。
CM7 ITCM ECCが有効になっている場合、ブートROMはCM7 ITCM ECCメモリを初期化し、NORフラッシュからCM7イメージをCM7 ITCMにコピーし、その後CM7をリセット状態から解放するのでしょうか？それとも、Boot ROMはCM7イメージだけを読み込み、CM33アプリケーションはCM7のリセット解除と起動を担当しているのでしょうか?
CM7 ITCM ECCが有効になっていない場合、ブートROMは、ロードアドレスがCM7 ITCM内にあるCM7イメージを検出したときにどのような動作をしますか？Boot ROMはCM7イメージをスキップしたり、ロードに失敗したり、CM7をリセット状態にしたり、コンテナのブートプロセス全体を失敗させたりしますか？
特に、以下のコンテナがサポートされているかどうかを確認したいです。
画像0：CM33
画像1：CM7
画像2：CM7
画像3：CM7
画像4：CM7
画像5：CM7
画像6：CM7
画像7：CM7
画像8：CM7
もしサポートされている場合、ブートROM起動時にこれら8つのCM7イメージは具体的にどのように処理されるのでしょうか？また、実際に実行されるCM7イメージを選択する役割を担うコンポーネントはどれでしょうか？
最後に、最大8つのOEMイメージエントリがコンテナに8つの異なるイメージを保存できるのか、それともBoot ROMが特定のコアに対して特定のイメージを選択して起動する仕組みを提供しているのかを明確にしたいと思います。