2138272_ja-JP

Yes

auth_cntr は戻り値を提供する必要がありますか?

OEM_Open モードで i.mx93 を使用して、無効に署名されたコンテナーの検出を検証していました。

u-bootの「\include\configs\imx93_evk.h」のコードauth_cntr が環境内の「if ステートメント」で使用できる値を返すことを意味します。

"auth_os=auth_cntr ${cntr_addr}\0" \
"mmcboot=echo Booting from mmc ...; " \
		"run mmcargs; " \
		"if test ${sec_boot} = yes; then " \
			"if run auth_os; then " \
				"run boot_os; " \
			"else " \
				"echo ERR: failed to authenticate; " \
			"fi; " \
		....

「if run auth_os; then」というチェックは、コンテナ検証の成功が戻り値として利用できるという印象を与えます。

ただし、テストでは、有効な署名付きコンテナーと無効な署名付きコンテナーの両方で、結果は常に「0」になることが示されています。ahab_status コマンドは、無効な署名済みコンテナを検証した後、エラーを報告します。

これは OEM_Open デバイスでは予想される動作ですか?あるいはimx93_evk.hファイルは存在しない何かを暗示していますか?

Security

Yocto Project

Re: Should auth_cntr provide a return value?

結果値は、auth_cntr コマンドの実行に関する情報のみを報告し、コンテナー自体が本物かどうかは報告しないようです。

OEM_Open シナリオでは、コンテナーが本物でない場合でも「run boot_os」が実行される可能性があります。

OEM_Closed シナリオの場合、auth_cntr を呼び出すとすぐに再起動されるSO、if ステートメントは完了しません。

Re: Should auth_cntr provide a return value?

セクション<10.9ガイドの「セキュリティリファレンスデザイン」が役立つかもしれません。

よろしくお願いします。

Harvey

Re: Should auth_cntr provide a return value?

私は i.MX93 ベースのボード上で yocto scarthgap ベースのイメージを実行しており、かなり古い 2022.04 u-boot を実行しています (現時点では)。

アイデアとしては、Ahab コンテナをいくつか用意するというものでした。
- 1番目のコンテナ: ELE、DDR FW、SPL
- 2番目のコンテナ: ATF、OP-TEE、U-Boot
- 3番目のコンテナ: カーネル
- 4番目のコンテナ: dtb
- ....n番目

すべてのコンテナは信頼チェーンを介して検証されます。1 番目は ROM の検証から始まり、2 番目は SPL、3 番目、4 番目は u-boot で、さらに追加のコンテナが検証されます。

u-boot の 3 番目と 4 番目のコンテナを確認するには、auth_cntr コマンドを使用します。その結果は ahab_status 経由で提供されます。ただし、これを bootcmd に追加して、各コンテナを検証し、障害発生時に停止するか回復モードに移行できるようにするというアイデアでした。

SO質問なのですが、自動化/スクリプト化された実装で auth_cntr をCAN使用すればよいのでしょうか?または、コード自体にこれらの手順/検証を追加し、これらのチェックを処理するカスタムコマンドを呼び出す方が、より適切/通常の方法でしょうか?

Re: Should auth_cntr provide a return value?

auth_os はカーネルとDTBで構築されたコンテナを検証します。ahab_status は検証された内容を報告するだけです。

どのバージョンの BSP をテストしていますか? また、どのような AHAB イベント情報をテストしていますか?

よろしくお願いいたします。

Harvey