背景：私は痞子衡氏が開発したNXP-MCUBootUtilityを使用して、i.MXRT106xのHABシグネチャに取り組んでいます。このツールにファームウェアのバイナリを読み込むと、次のように表示されます:**ブート可能なファイルヘッダーから有効な割り込みベクターテーブルアドレスが見つからない**。
バイナリを16進エディタで検査した後：
- IVTエントリポイントは`0x20209401`、イメージロードベースアドレスは`0x20208000`で、これはファイルオフセット`0x1400`に対応します。
- このコードセグメントは、オフセット `0x2000` までのブート関連のブートデータフローと同一です。
- 通常、IVTエントリはリセットベクタアドレスを指す必要があります（参照例ではオフセット`0x2005`を指しています）。しかし、私のファームウェアでは、IVTエントリはオフセット`0x1400`を指しています。これがツール解析エラーの根本原因だと推測されます。
CSTワークフローに関するさらなる調査：
CST署名の高レベルなロジックは理解しています。ファームウェア内の空きブロックを見つけ、IVT CSFポインタをこの場所に設定し、標準のCSFテンプレートを使用し、`[Authenticate Data]`ブロックセクションを変更して、署名検証の開始アドレスとサイズ範囲を設定します。
私のファームウェアは、FCB、IVT、DCD、およびブートデータを含む完全な起動可能なイメージであり、HABクロージャなしでハードウェア上で正常に起動します。
CSFブロックを以下のように設定しました。
Blocks=0x20208000 0x1000 0x126c0 "my_firmware.bin"また、証明書のパスもそれに合わせて更新しました。
CST v3.00.01 コマンドを実行しました。
cst.exe -i .\input_resign.csf -o sig.binCSTの実行はエラーなく完了し、`sig.bin`が生成されました。
出力と元のバイナリを比較すると、正確には2つの変更点があります。
1. IVT内のオフセット`0x1018`にあるCSFポインタフィールドが更新されます。
2. CSFシグネチャデータはオフセット`0x136c0`に追加されます。
この署名済みイメージをハードウェアに書き込むと：
1.HABが閉じられていない（SEC_CONFIGが閉じられていない）場合、ファームウェアは正常に動作します。
2. SRKヒューズビットを書き込み、HABを閉じた後、ファームウェアが起動に失敗します。
JTAG経由でメモリアドレス`0x2020523c`から長さ256バイトのHABログをダンプしました。ログの内容は以下のとおりです。
-----------------------------------------------------------------------------------------
| Log Entry | Description
-----------------------------------------------------------------------------------------
0x00010002: BOOTMODE_INTERNAL
0x000200cc: SEC_CONFIG_CLOSED
0x00030001: DIR_BT_DIS_VALUE1
0x00040000: BT_FUSE_SEL_VALUE0
0x00050000: PRIM_IMAGE_SELECT
0x00060008: PRIM_BOOTDEVICE_FLEXSPI_NOR
0x00070000: DEVICE_INIT_CALL
0x000700f0: DEVICE_INIT_PASS
0x00090000: AUTHENTICATION_STATUS**私の質問:**
1.実際のHABイベントコードはどこにありますか?参考文献によると、HAB認証の合格/失敗は明示的なイベントコードを生成するはずです。しかし、私のログは『AUTHENTICATION_STATUS』で止まり、その後のイベントエントリーはありません。HAB認証が成功したか失敗したかをどうやって判断すればいいですか?
2. 「blhost」ツールを試しましたが、i.MXRT1061でHABログ読み取りコマンドが動作するのを見つけられません。HABの完全な状態を読み取る他の方法はありますか?
3. 私の署名ワークフローは有効か?私のイメージでは、非標準のIVTエントリポイントを使用しています（リセットベクタオフセット`0x2005`ではなく、オフセット`0x1400`を指しています）。このような画像はCSTで正しくHAB署名できますか?
オフセット`0x1000`にある追加のIVTヘッダーバイト:
D1 00 20 40 01 94 20 20 00 00 00 00 80 90 20 20
20 90 20 20 00 90 20 20 00 00 00 00 00 00 00 00
00 80 20 20 80 99 01 00 00 00 00 00 00 80 20 20
80 99 01 00 52 44 49 52 00 00 00 00 E4 B8 21 20
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 D2 00 08 41 CC 00 04 04
CSTツールバージョン：3.00.01
こんにちは、 @eleven さん。
最新情報のご提供ありがとうございます。まず、boot.binの最初のバイトがFCBなのかIVTなのかを確認する必要があると思います。FCBの場合、位置合わせの問題がまだ残っている可能性があります。
さらに、HAB障害コードの読み取りと解釈のプロセスにおいて、このガイドが役立つはずです。https: //community.nxp.com/t5/i-MX-Security/HAB-event-in-a-Closed-i-MX-chip/ta-p/1120239
それでも問題の根本原因を特定できない場合は、MCUBootUtilityを使用してHAB署名を直接生成し、バイナリ差分を実行することで、結果を相互検証できる可能性があります。
よろしくお願いします、
ギャビン
詳細なご回答をいただき、誠にありがとうございました。最初の投稿で、テスト環境について十分に説明できていなかったと思います。
ご提案いただいたとおり、ブロック設定の調整は既に試してみました。私は両方を試しました。
ブロック = 0x20208000 0x1000 0x126c0 "my_firmware.bin"
そして、IVTからファームウェアの最後まで認証を行うために、複数のブロックエントリに分割します。
ブロック = 0x20209000 0x0 0x40 "boot.bin",\
0x20209080 0x80 0xf80 "boot.bin",\
0x2020a000 0x1000 0x11c00 "boot.bin"
私の意図は、IVTからアプリケーションコードの最後まで認証することでした。しかし、これらの変更後も起動時の動作は変化しなかった。
私はMCUBootUtility v6.5.1を使用しています。内蔵のブートログ解析と手動のJTAGメモリダンプは、どちらも全く同じログ結果を示す。
また、NORフラッシュメモリの最小ブートオフセットは0x1400であると理解しています。私が明確にしたかったのは、私のIVTエントリポイントは、参照例に見られるようなオフセット0x2005にある一般的なリセットベクタではなく、ブート関連のコードを指しているということです。
ご指導いただき、改めて感謝申し上げます。デバッグ情報をさらに収集するために、sdphostを使用して追加のテストを実行します。そこからもっと手がかりが得られればいいのですが。
よろしくお願いします、
11
こんにちは、 @eleven さん。
IVTデータ、CST構成、およびROMログに基づいて、いくつかの潜在的な問題点を特定しました。
1. CST [Authenticate Data] Blocks アドレス/オフセットの不一致（主要な問題）
あなたの画像から、 BootData.start = 0x20208000とIVT.self = 0x20209000によってマッピングが確立されます。ファイルオフセット0x1000メモリアドレス0x20209000に対応し、 0x20208000には対応しません。
CST Blocks の構文は
Blocks = 0x20208000 0x1000 0x126c0 "my_firmware.bin" ← address/offset misaligned by 0x1000
CSTはファイルオフセット0x1000のデータに署名し、デバイス上のHABは0x20208000（=ファイルオフセット0）のメモリを検証します。2つは4 0x1000でオフセットされているため、署名が一致することは決してありません。これはまさに「オープンモードでは起動し、クローズモードでは失敗する」という現象を説明しています。オープンモードでは、HAB検証の失敗はログに記録されるだけで（致命的ではない）、クローズモードでは実行がブロックされます。
修理 ：
(sign from IVT): Blocks = 0x20209000 0x1000 0x126c0 "my_firmware_prepared.bin"
また、CST を実行する前に、IVT.csf フィールド (オフセット 0x1018) に最終的な CSF アドレス 0x2021b6c0 (= 0x20208000 + 0x136c0) が事前に設定されていることを確認し、その後署名し、追加します。署名後は署名済みバイトを変更しないでください(IVT/BootData/DCDはすべて署名範囲内です)。そうすると検証も壊れます。
Q1: HABイベントコードはどこにありますか?合否判定の方法は？
0x2020523cから読まれているのはROMブートログであって、詳細なHABイベントログではありません。RT10xxでは、各エントリは(event_id<<16) | parameterとして単一の32ビットワードにパックされ、パラメータは下位バイトに格納されます。
詳細な失敗理由については、HAB ROM API: report_status(&config,&state) および report_event(status,index,event,&bytes) を呼び出してください。decode per HAB4 API リファレンス・マニュアル、付録A
Q2:blhostがHABログを読み取れません — 他に方法はありますか?
blhost ブートROMに直接ではなく、フラッシュローダーと通信します。i.MXRT BootROMのシリアルダウンロード段階はSDPのみをサポートしています( sdphostをご利用ください)。オプション:
- 推奨: オープン 状態のアプリケーションからHAB APIを呼び出して、ステータスやイベント情報を読み込み印刷してください。
- JTAG (ROMログ) を介して
0x2020523cから 256 バイトをダンプするか、MCUBootUtility v6.3 (sdphost がフラッシュローダーをロードし、次に blhost がメモリを読み込む) を使用して自動解析を行います。
重要事項: クローズドで認証が失敗すると、ROMはアプリケーションにジャンプせず、アプリ内 report_event は実行できません。したがって、標準フローはまず開閉状態で HAB_SUCCESS/イベント情報なしを確認し、その後SEC_CONFIG燃焼して閉じる必要があります。
Q3: 非標準IVTエントリー(オフセット0x1400)はHAB署名できますか?
はい、これは原因ではありません。NORブートの場合、i.MXRT BootROMの最小オフセットは0x1400です（0x2000は推奨値です）。
よろしくお願いします、
ギャビン
またお手数をおかけして申し訳ありませんが、この問題は私にとって非常に重要なのです。
sdphostコマンドを使ってHAB認証エラーを明確に観察できました。次にJTAG経由で初期メモリ領域をダンプしてみたところ、ファームウェアの内容はメモリ上に全く存在しないことがわかった。
さらなるテストの結果、NXP-MCUBootUtilityに同梱されている公式デモプロジェクトでさえ、NON-XIPとして構成した場合、HAB署名に失敗することが判明した。XIPベースのイメージのみが正常に動作します。この結果にはとても驚きました。
私のeFuseレジスタの設定に間違いがあるのではないかと考えています。私のボードにはブートモードのDIPスイッチがないため、boot_cfgを0x1AにしてSRKヒューズを焼き切っただけです(添付のスクリーンショットを参照してください)。
私はこの分野の初心者なので、単純なミスをしているかもしれません。訂正やご提案があれば、ぜひお聞かせください。
ご返信をお待ちしております。よろしくお願いいたします。
こんにちは、 @eleven さん。
あなたの指摘（公式デモでさえ、非XIPでビルドするとHABが失敗し、XIPでビルドすると動作する）は、以下の記事の根本原因を示しているようです： https://www.cnblogs.com/henjay724/p/18111727
RT1050/1060「Non-XIP + HAB」ブートROM制限 これら2つの初期デバイスでは、BootROMはOCRAMの一部(特に 0x20280000–0x202BFFFF)を予約し、HAB認証には開放しません。他のRTデバイスにはこの制限はありません。イメージはOCRAM(0x20208000)に読み込まれるので、HABをオフにして起動しますが、HABオンの状態で検証に失敗し、ファームウェアはメモリにコピーされません。これは脳脊髄液/ブロックとは無関係であるため、以前の変更は効果がなかったのです。
非XIPが必要な場合は、予約済みのOCRAM領域を避け、代わりに外部SDRAMを使用してください。あるいは、上記のリンク先のガイドによると、画像は有害藻類ブルームの認識領域内に厳密に限定されなければならない。
ヒューズについて（スクリーンショット）：
- ブートモードのディップ・スイッチがない場合、スタンドアロン起動には BT_FUSE_SEL = 1が必要です。そうでなければ起動構成は定義されていません。
- また、
BOOT_CFG1=0x1AとConf0=0x40をRT1060 RMのヒューズマップと比較してビットごとに検証してください。ヒューズはOTP（一度書き込み可能）です。慎重に作業を進めてください。
よろしくお願いします、
ギャビン