gt777
2023年6月9日 11時21分
お世話になっております。
Armadillo-IoT ゲートウェイ G4で開発しております。
セキュアブート（ストレージの暗号化）用イメージをインストールする方法について、
SDブートではなくSWUpdateを利用することは可能でしょうか？
「セキュリティガイド 5.7. ストレージの暗号化のセットアップ」を参考に「baseos-[VERSION].[DATE].tar.zst」を作成し、
「製品マニュアル 9.7.3. Alpine Linux ルートファイルシステムをビルドする」を参考に.swuイメージの作成まで実施したのですが、
「セキュリティガイド 5.8.2. SRK ハッシュの書き込み」とSWUpdateの順序関係がわからず先に進めていない状況です。
また、SWUpdateが利用可能な場合、ストレージ暗号化の範囲指定（SD boot ディスク作成時の--encrypt allオプション）の指定方法も教えてください。
コメント
gt777
マルティネさん
詳細なご説明ありがとうございます。
SWUpdateを利用する場合の具体的な手順について確認させてください。
参照するマニュアルと章を書き出してみましたが、合っていますでしょうか。
> * 暗号化されてない、証明済みの u-boot/linux を書き込む
セキュリティガイド 5.5. セキュアブートのセットアップ
製品マニュアル 9.7.3. Alpine Linux ルートファイルシステムをビルドする
> * それに切り替える
swupdate -d '-u [swuイメージURL]'でインストール
> * その u-boot から SRK/close処理を行って、リセットする（リセットしないと適用されないのでご注意ください）
セキュリティガイド 5.8.2. SRK ハッシュの書き込み
セキュリティガイド 5.8.3. close 処理
> * 必要な場合に暗号化のためもう一度インストールしる
セキュリティガイド 5.7. ストレージの暗号化のセットアップ
★u-boot/linuxは1つ目のswuと同一のものを指定すればよいのでしょうか？
ブートローダーは「enable_disk_encryption.desc」ではなく「encrypted_imxboot_update.desc」を指定でしょうか？
製品マニュアル 9.7.3. Alpine Linux ルートファイルシステムをビルドする
swupdate -d '-u [swuイメージURL]'でインストール
> *（そこに切り替えた後に平文の rootfs を再び上書きする。マニュアルに紹介されてませんが、セキュアブートを使う場合は、インストールの後に動作確認を行って、大丈夫な場合に「abos-ctrl rollback-clone」で古い面を更新することを推奨します）
★こちらの手順はどこを参照すれば良いでしょうか？
> > また、SWUpdateが利用可能な場合、ストレージ暗号化の範囲指定（SD boot ディスク作成時の--encrypt allオプション）の指定方法も教えてください。
> - swdesc_option ENCRYPT_USERFS で build_image.sh の --encrypt userfs とほぼ同じ結果で、 /var/log と appfs が暗号化されます。
> - swdesc_option ENCRYPT_ROOTFS で rootfs も暗号化します。 build_image.sh の --encrypt all と userfs の差だけです（両方を設定する必要があります）
セキュリティガイド 5.7.5. セキュアブート対応 swu の作成
で使用している「enable_disk_encryption.desc」に上記2つのオプションの記載があったので、--encrypt allオプションをつけずとも（/opt/firmware以外は）暗号化されているということでしょうか
ご確認よろしくお願いいたします。
at_dominique.m…
gt777さん
> > * 暗号化されてない、証明済みの u-boot/linux を書き込む
> セキュリティガイド 5.5. セキュアブートのセットアップ
> 製品マニュアル 9.7.3. Alpine Linux ルートファイルシステムをビルドする
はい
> > * それに切り替える
> swupdate -d '-u [swuイメージURL]'でインストール
はい
> > * その u-boot から SRK/close処理を行って、リセットする（リセットしないと適用されないのでご注意ください）
> セキュリティガイド 5.8.2. SRK ハッシュの書き込み
> セキュリティガイド 5.8.3. close 処理
はい。開発機に一度 5.8.2 SRK ハッシュの書き込みの後、一度リセットして hab_status を確認することを推奨します。（マニュアルのとおりですね）
> > * 必要な場合に暗号化のためもう一度インストールしる
> セキュリティガイド 5.7. ストレージの暗号化のセットアップ
> ★u-boot/linuxは1つ目のswuと同一のものを指定すればよいのでしょうか？
> ブートローダーは「enable_disk_encryption.desc」ではなく「encrypted_imxboot_update.desc」を指定でしょうか？
u-boot も暗号化する場合は「5.6.3. 署名済みの暗号化ブートローダーの作成」を別でビルドした物も使えますが、1つ目の swu と同じ物でも動きます。
mkswu の段階で暗号化済みの u-boot を使う場合は swdesc_boot_enc imx-boot_armadillo_x2.enc armadillo_x2.dek_offsets (5.6.5. 暗号化セキュアブート対応 swu の作成)、u-boot が暗号化されてない場合は普通の「swdesc_boot imx-boot_armadillo_x2.signed」で設定してください（ページに暗号化無しの例がないですね…）
linux カーネルの方はカーネルの暗号化をサポートしてませんので、一つ目の SWU と同じ物でいいです… が、
linux イメージは 「swdesc_boot_linux Image.signed」で書き込み直してください。
言葉として swdesc_boot_linux はでてませんが、「5.10. セットアップ完了後のアップデートの運用について」の「encrypted_rootfs_linux_update.desc」を参考にできます。
u-boot が暗号化済みの rootfs を読み取れないので、/dev/mmcblk2bootX に書き込んでいます。
※ 試してlinux カーネルの暗号化もできますが、初期のimx-boot の不具合で最初のリリースに使えなかったので対応はリクエスト次第です。
> 製品マニュアル 9.7.3. Alpine Linux ルートファイルシステムをビルドする
>
> swupdate -d '-u [swuイメージURL]'でインストール
はい
> > *（そこに切り替えた後に平文の rootfs を再び上書きする。マニュアルに紹介されてませんが、セキュアブートを使う場合は、インストールの後に動作確認を行って、大丈夫な場合に「abos-ctrl rollback-clone」で古い面を更新することを推奨します）
> ★こちらの手順はどこを参照すれば良いでしょうか？
rollback-clone コマンドは数ヶ月前に追加したばかりで、まだ「試し期間」という形で完全にドキュメント不足です…
サンプルの「確認してからクローンします」サービスを用意してから公式にマニュアルに足したかったがその時間を見つからなくて、終わってません。
コマンド自体は動いてますが、すみません、言うべきではなかったと改めました。再び何かの swu をインストールした方が分かりやすいと思いますが、試していただけたら質問に答えます。
（コマンドは引数無しで、現在の rootfs/appfs のパーティションを B面にコピーするだけの実装です）
> > > また、SWUpdateが利用可能な場合、ストレージ暗号化の範囲指定（SD boot ディスク作成時の--encrypt allオプション）の指定方法も教えてください。
> > - swdesc_option ENCRYPT_USERFS で build_image.sh の --encrypt userfs とほぼ同じ結果で、 /var/log と appfs が暗号化されます。
> > - swdesc_option ENCRYPT_ROOTFS で rootfs も暗号化します。 build_image.sh の --encrypt all と userfs の差だけです（両方を設定する必要があります）
>
> セキュリティガイド 5.7.5. セキュアブート対応 swu の作成
> で使用している「enable_disk_encryption.desc」に上記2つのオプションの記載があったので、--encrypt allオプションをつけずとも（/opt/firmware以外は）暗号化されているということでしょうか
はい、そのオプションは文字として出てませんでしたが、「enable_disk_encryption.desc」の中身を確認したところ今説明した設定のことでした。
マニュアルのとおりでほぼ大丈夫ですが、「encrypted_rootfs_linux_update.desc」が initial_setup_encryption.swu の作成のコマンドから抜けました。
例のファイルと同じ名前でしたら、「mkswu initial_setup.desc encrypted_rootfs_linux_update.desc enable_disk_encryption.desc encrypted_imxboot_update.desc -o initial_setup_encryption.swu」で設定できると思いますが、
管理のために一つのファイルにまとめた方がいいかもしれません。
よろしくお願いします。
gt777
マルティネさん
ご確認いただきありがとうございます。
> linux カーネルの方はカーネルの暗号化をサポートしてませんので、一つ目の SWU と同じ物でいいです… が、
> linux イメージは 「swdesc_boot_linux Image.signed」で書き込み直してください。
> 言葉として swdesc_boot_linux はでてませんが、「5.10. セットアップ完了後のアップデートの運用について」の「encrypted_rootfs_linux_update.desc」を参考にできます。
> 例のファイルと同じ名前でしたら、「mkswu initial_setup.desc encrypted_rootfs_linux_update.desc enable_disk_encryption.desc encrypted_imxboot_update.desc -o initial_setup_encryption.swu」で設定できると思いますが、
セキュリティガイド 5.7.5. セキュアブート対応 swu の作成にてmkswuコマンドを投入したら
以下のようにエラーとなってしまうのですが、どこに問題があるかわかりますでしょうか。
atmark@atde9:~/mkswu$ mkswu initial_setup.desc encrypted_rootfs_linux_update.desc \ enable_disk_encryption.desc encrypted_imxboot_update.desc -o initial_setup_encryption.swu initial_setup.desc を組み込みました。 stat: cannot statx 'Image.signed': そのようなファイルやディレクトリはありません /usr/bin/mkswu: 854: [: Illegal number: ERROR: swdesc_boot_linux は 26MB までです。 atmark@atde9:~/mkswu$ cat encrypted_rootfs_linux_update.desc # This example is intended for users with ENCRYPTED_ROOTFS. # Ignore it if not using encryped rootfs. # version must be updated everytime like normal updates swdesc_option version=2 # Image.signed is an a linux image with initrd built using # imx-boot/secureboot.sh linux swdesc_boot_linux "Image.signed"
mkswuフォルダ直下に"Image.signed"をコピーして配置してみたのですが、エラーの内容が変わっただけで組み込めませんでした。
atmark@atde9:~/mkswu$ mkswu initial_setup.desc encrypted_rootfs_linux_update.desc enable_disk_encryption.desc encrypted_imxboot_update.desc -o initial_setup_encryption.swu initial_setup.desc を組み込みました。 ERROR: ファイルが見つかりませんでした。
お手数ですがご確認をお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| swupdateイメージ作成.log | mkswuコマンド投入時ログ |
at_dominique.m…
gt777さん
> stat: cannot statx 'Image.signed': そのようなファイルやディレクトリはありません > /usr/bin/mkswu: 854: [: Illegal number: > ERROR: swdesc_boot_linux は 26MB までです。
推測のとおりにファイルの位置の問題でした。
確かに分かりにくいので、「xxxファイルが存在しない」でエラーするように直しておきます。
> atmark@atde9:~/mkswu$ mkswu initial_setup.desc encrypted_rootfs_linux_update.desc enable_disk_encryption.desc encrypted_imxboot_update.desc -o initial_setup_encryption.swu > initial_setup.desc を組み込みました。 > ERROR: ファイルが見つかりませんでした。
すみません、swdesc_boot_linux のテスト不足で、 リファクタリングで4月のアップデートでこのコマンドの不具合になりました。
これも直しましたので、次のリリースまでに https://github.com/atmark-techno/mkswu の 「test」ブランチから直接に mkswu を実行していただければ助かります。
$ git clone -b test https://github.com/atmark-techno/mkswu $HOME/mkswu/mkswu $ $HOME/mkswu/mkswu/mkswu initial_setup.desc encrypted_rootfs_linux_update.desc enable_disk_encryption.desc encrypted_imxboot_update.desc -o initial_setup_encryption.swu
お手数ですが、またエラーございましたらご連絡ください。
よろしくお願いします。
gt777
マルティネさん
mkswuの修正ありがとうございました。エラーなく作成できました。
署名済みSWUイメージをインストールしてみたのですが、以下のようにhab_statusでエラーとなってしまっております。。
u-boot=> hab_status Secure boot disabled HAB Configuration: 0xf0, HAB State: 0x66 --------- HAB Event 1 -----------------
手順として不安なのは以下なのですが、問題ありますでしょうか。
また、ここからの復旧手順についてわかりますでしょうか。
SRKはprint_srk_fuseで取得した値で問題なく設定できているように見えております。
・SWUイメージにinitial_setup.descを組み込みましたが、問題ありましたでしょうか
atmark@atde9:~/build-rootfs-v3.17-at.6$ mkswu ../mkswu/initial_setup.desc OS_signed.desc -o OS_signed_init.swu ../mkswu/initial_setup.desc を組み込みました。 OS_signed.desc を組み込みました。 OS_signed_init.swu を作成しました。
・swupdateコマンド投入後、自動で再起動された際、u-bootのプロンプト起動が間に合わず、
一度電源断→電源再投入してしまったのですが、問題ありますでしょうか。
at_dominique.m…
gt777さん、
> u-boot=> hab_status > > Secure boot disabled > > HAB Configuration: 0xf0, HAB State: 0x66 > > --------- HAB Event 1 -----------------
その HAB Event 1 のすぐ下に hex dump と cause 等が表示されていたはずですが、表示されてませんでしたか？
表示されたらそれも含めてコピーしてください。
（手元のサインされてない物で例えばこうなっています：
event data: 0xdb 0x00 0x08 0x45 0x33 0x11 0xcf 0x00 STS = HAB_FAILURE (0x33) RSN = HAB_INV_CSF (0x11) CTX = HAB_CTX_CSF (0xCF) ENG = HAB_ENG_ANY (0x00)
)
> 手順として不安なのは以下なのですが、問題ありますでしょうか。
送っていただいた「swupdateイメージ作成.log」の中に「./secureboot.sh imxboot_enc」署名だけの「imxboot」（imx-boot_armadillo_x2.signed）も作成して、OS_signed.desc に使ってますでしょうか？（「swdesc_boot imx-boot_armadillo_x2.signed」として）
> また、ここからの復旧手順についてわかりますでしょうか。
> SRKはprint_srk_fuseで取得した値で問題なく設定できているように見えております。
確認のため、「secureboot.sh print_srk_fuse」とu-boot側の「fuse read 6 0 4; fuse read 7 0 4」の出力も確認してください。
公開鍵の方なので、こちらにも提供していただけたら嬉しいですが、そちらの確認でできたら信じておきます。
> ・SWUイメージにinitial_setup.descを組み込みましたが、問題ありましたでしょうか
desc の内容をみないと何ともいえませんが、大丈夫そうですね。
ちなみに「mkswu --show OS_signed_init.swu」で最終確認できます（パスワードのハッシュが表示されますので、OS_signed.desc の部分だけをお願いします）
また、initial setup は一度しかインストールできませんので、armadillo の cat /var/at-log/atlog にアップデートの記録を確認してください。
swupdateコマンドの後に再起動したので問題ないと思いますが、swu の一部が無視された可能性もあります（例えば、「boot」のバージョンが変わってなかったので、imx boot だけをインストールしなかったなど）
その点については起動ログの出力にビルド時間が表示されてますので、そこでも確認できればと思います。
> ・swupdateコマンド投入後、自動で再起動された際、u-bootのプロンプト起動が間に合わず、
> 一度電源断→電源再投入してしまったのですが、問題ありますでしょうか。
問題ないです。起動スクリプトは secure boot に関する物を無視していますので、起動や再起動することで悪影響はありません。
よろしくお願いします。
gt777
マルティネさん
> その HAB Event 1 のすぐ下に hex dump と cause 等が表示されていたはずですが、表示されてませんでしたか？
> 表示されたらそれも含めてコピーしてください。
> 確認のため、「secureboot.sh print_srk_fuse」とu-boot側の「fuse read 6 0 4; fuse read 7 0 4」の出力も確認してください。
> 公開鍵の方なので、こちらにも提供していただけたら嬉しいですが、そちらの確認でできたら信じておきます。
→添付します。
> 送っていただいた「swupdateイメージ作成.log」の中に「./secureboot.sh imxboot_enc」署名だけの「imxboot」（imx-boot_armadillo_x2.signed）も作成して、OS_signed.desc に使ってますでしょうか？（「swdesc_boot imx-boot_armadillo_x2.signed」として）
→コマンドログ見返してみましたが、「./secureboot.sh imxboot」で生成した「swdesc_boot imx-boot_armadillo_x2.signed」を使っています。
atmark@atde9:~/imx-boot-2020.04-at14$ ./secureboot.sh imxboot atmark@atde9:~/imx-boot-2020.04-at14$ ls -lrth ../secureboot atmark@atde9:~/imx-boot-2020.04-at14$ vi secureboot.conf atmark@atde9:~/imx-boot-2020.04-at14$ ./secureboot.sh linux atmark@atde9:~/imx-boot-2020.04-at14$ ls -ltrh ../secureboot atmark@atde9:~/imx-boot-2020.04-at14$ cd atmark@atde9:~$ cp secureboot/Image.signed build-rootfs-v3.17-at.6/ax2/resources/boot/Image atmark@atde9:~$ cd build-rootfs-v3.17-at.6 atmark@atde9:~/build-rootfs-v3.17-at.6$ sudo ./build_rootfs.sh --cache ../baseos-x2-3.17.3-at.6.cache.tar atmark@atde9:~/build-rootfs-v3.17-at.6$ ls -ltrh atmark@atde9:~/build-rootfs-v3.17-at.6$ vi OS_signed.desc atmark@atde9:~/build-rootfs-v3.17-at.6$ mkswu ../mkswu/initial_setup.desc OS_signed.desc -o OS_signed_init.swu
> desc の内容をみないと何ともいえませんが、大丈夫そうですね。
> ちなみに「mkswu --show OS_signed_init.swu」で最終確認できます（パスワードのハッシュが表示されますので、OS_signed.desc の部分だけをお願いします）
> また、initial setup は一度しかインストールできませんので、armadillo の cat /var/at-log/atlog にアップデートの記録を確認してください。
> swupdateコマンドの後に再起動したので問題ないと思いますが、swu の一部が無視された可能性もあります（例えば、「boot」のバージョンが変わってなかったので、imx boot だけをインストールしなかったなど）
> その点については起動ログの出力にビルド時間が表示されてますので、そこでも確認できればと思います。
→添付します。
よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| boot関連情報.txt |
at_dominique.m…
gt777さん、
> > 確認のため、「secureboot.sh print_srk_fuse」とu-boot側の「fuse read 6 0 4; fuse read 7 0 4」の出力も確認してください。
> > 公開鍵の方なので、こちらにも提供していただけたら嬉しいですが、そちらの確認でできたら信じておきます。
>
> →添付します。
ありがとうございます、大丈夫そうですね。
> →コマンドログ見返してみましたが、「./secureboot.sh imxboot」で生成した「swdesc_boot imx-boot_armadillo_x2.signed」を使っています。
atlog のファイルに以下のバージョンが上がってます：
* other_boot: unset -> 2020.04-at10 これはインストールではなく、B面のバージョンの記録だけです
* extra_os.initial_setup: unset -> 3 initial_setup.desc のバージョンですね。
* base_os: 3.16.3-at.6 -> 3.17.3-at.6.20230609.1 OS_signed のバージョンですね。
なので、imx_boot-armadillo_x2.signed がインストールされませんでした。
swdesc_boot を使った desc ファイルを mkswu コマンドに使っていたことも確認できますか？
使った場合に mkswu --show のさいに「swdesc_boot ... --version boot 2020.4... 」が記載されていると思いますが、2020.4-at10 と一致した場合にインストールされませんのでそこが問題になっていたかもしれません。
その場合は、u-boot ディレクトリに localversion ファイルを編集して u-boot のバージョンをu-boot 側で変えるか、swdesc_boot --version boot 2020.4-at10.signed.1 等で指定してください。（このバージョンの説明は短く TEE のページにありますが、セキュアーブートになかったんですね…これも修正したいと思います）
initial_setup はもうできてますので、今度は initial_setup.desc 無しでカスタムな部分だけの .desc ファイルで swu をビルドしてください。
よろしくお願いします。
gt777
マルティネさん
ご確認ありがとうございます。
> > →コマンドログ見返してみましたが、「./secureboot.sh imxboot」で生成した「swdesc_boot imx-boot_armadillo_x2.signed」を使っています。
すみません、質問を勘違いしていたかもしれません。
OS_signed.descのファイル内に「swdesc_boot imx-boot_armadillo_x2.signed」の記載が必要だったでしょうか？
現状書かれていません。
atmark@atde9:~/build-rootfs-v3.17-at.6$ cat OS_signed.desc
swdesc_tar --version base_os 3.17.3-at.6.20230609.1 \
--preserve-attributes baseos-x2-3.17.3-at.6.20230609.tar.zstセキュリティガイドではSDブートディスクの作成の際に使用するようになっているんですね。。
以下のようにdescを修正し、mkswuでswuイメージを生成・インストールすればよいでしょうか？
atmark@atde9:~/build-rootfs-v3.17-at.6$ cat OS_signed.desc
swdesc_tar --version base_os 3.17.3-at.6.20230609.2 \
--preserve-attributes baseos-x2-3.17.3-at.6.20230609.tar.zst
swdesc_boot imx-boot_armadillo_x2.signed
atmark@atde9:~/build-rootfs-v3.17-at.6$ mkswu OS_signed.descgt777
マルティネさん
連続ですみません。
swuイメージを作り直してインストールしたところ、
鍵が一致したように見えました。ありがとうございます。
ただ、「Secure boot enabled」ではなく「disabled」と表示されているのですが、
これはclose処理をしていないからでしょうか？
u-boot=> hab_status Secure boot disabled ←enabledにならない HAB Configuration: 0xf0, HAB State: 0x66 No HAB Events Found!
よろしくお願いいたします。
at_dominique.m…
gt777さん
> OS_signed.descのファイル内に「swdesc_boot imx-boot_armadillo_x2.signed」の記載が必要だったでしょうか？
分かりにくい仕様ですみません、そうです。
証明済みの uboot + linux がなければ、secure boot を有効にした時に起動できなくなりますので、両方が必要です。
> 以下のようにdescを修正し、mkswuでswuイメージを生成・インストールすればよいでしょうか？
もう試しましたが、はい、これで大丈夫です。
> swuイメージを作り直してインストールしたところ、
> 鍵が一致したように見えました。ありがとうございます。
よかったです！
> ただ、「Secure boot enabled」ではなく「disabled」と表示されているのですが、
> これはclose処理をしていないからでしょうか？
はい、close処理しない限り secure boot ではないので、close 処理で enabled になります。
ここで hab event がなくなったので、close しても u-boot に入れますね。
linux の方はチェックされてませんが、セキュリティガイドに linux の確認までは書いてないですね…
hab_auth_img でできますが IVT の位置まで指定しないと確認できないのでかなり面倒な手順で、大丈夫の前提で進んでいいと思います。
（u-boot が動きますので、万が一問題あったら SD で救えます。u-boot の証明が成功したところで linux の方が失敗することもあまりないと思いますし）
よろしくお願いします。
gt777
マルティネさん
ご確認ありがとうございます。
close、resetを実施し、セキュアブートが正常に動いたように見えました。ありがとうございました。
ストレージ暗号化の設定のため、「セキュリティガイド 5.7. ストレージの暗号化のセットアップ」で作成したSWUイメージをSWUpdateで適用してみたのですが、
エラーは出ていませんが正常に暗号化ができていないようです。
どこを確認すればよいかわかりますでしょうか。
| ファイル | ファイルの説明 |
|---|---|
| ストレージ暗号化適用.log |
at_dominique.m…
gt777さん
> close、resetを実施し、セキュアブートが正常に動いたように見えました。ありがとうございました。
分かりにくくてすみません、よかったです。
> ストレージ暗号化の設定のため、「セキュリティガイド 5.7. ストレージの暗号化のセットアップ」で作成したSWUイメージをSWUpdateで適用してみたのですが、
> エラーは出ていませんが正常に暗号化ができていないようです。
swu の内容がちょっと気になります。添付していただいたファイルでは、以下の内容が入ってます：
1/ initial_setup_encryption:
a- initial_setup.desc
b- 証明済みの、ディスク暗号化用カーネル (swdesc_boot_linux Image.signed)
c- ディスク暗号化変数 (ENCRYPT_ROOTFS/USERFS)
d- 暗号化済みの u-boot (swdesc_boot_enc)
2/ OS_enc:
a- baseOS イメージ
b- 普通の u-boot (swdesc_boot)
一方、at-log では以下の内容がインストールされたそうです：
1/ initial_setup + base_os
2/ u-boot (証明済みイメージ？）+ base_os
3/ base_os
なので、ディスク暗号化用のカーネルなどがインストールされてません。そこでディスク暗号化変数のイメージがインストールされてなかったと考えていますが、どうでしょうか。
なにもない状態から考えたら理想な順番は：
1/ initial_setup + 証明済みカーネルを含む base_os + 証明済み u-boot
2/ srk, close処理
3/ 暗号化用カーネル（swdesc_boot_linux) + 暗号化済み u-boot (swdesc_boot_enc) + ディスク暗号化変数（baseos はA面からコピーされてますので厳密には不要ですが、入れても害はありません）
今は 2/ の後の状態に近いですので、再び 3/ の swu を作ってみてインストールしてください。
ちなみに今更ですが、セキュリティガイドの確認でカーネルのモジュールをインストールしていないことに気づきました。https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro… の「ビルドしたカーネルは、以下に示すどちらかの方法でインストールしてください」の二つ目の make ... modules_install を行わないと不具合が出ると思いますので、お手数ですがしてなかったら baseos のアーカイブを更新してください。（今回の問題には関係ないですが…）
よろしくお願いします。
gt777
マルティネさん
> 3/ 暗号化用カーネル（swdesc_boot_linux) + 暗号化済み u-boot (swdesc_boot_enc) + ディスク暗号化変数（baseos はA面からコピーされてますので厳密には不要ですが、入れても害はありません）
「セキュリティガイド 5.7. ストレージの暗号化のセットアップ」のようにinitial_setup_encryption.swuを作成するのではなく、直接OS_enc.swuに暗号化用カーネル（swdesc_boot_linux) + 暗号化済み u-boot (swdesc_boot_enc) + ディスク暗号化変数を入れるということでしょうか？
atmark@atde9:~/mkswu$ cat encrypted_rootfs_linux_update.desc ★暗号化用カーネル
swdesc_option version=2
swdesc_boot_linux "../secureboot/Image.signed"
atmark@atde9:~/mkswu$ cat encrypted_imxboot_update.desc ★暗号化済みu-boot
swdesc_option version=2
swdesc_boot_enc "../secureboot/imx-boot_armadillo_x2.enc" "../secureboot/armadillo_x2.dek_offsets"
atmark@atde9:~/mkswu$ cat enable_disk_encryption.desc ★ディスク暗号化変数
swdesc_option component=extra_os.disk_encryption
swdesc_option version=1
swdesc_option ENCRYPT_ROOTFS
swdesc_option ENCRYPT_USERFS
swdesc_command true
atmark@atde9:~/build-rootfs-v3.17-at.6$ cat OS_enc.desc
swdesc_tar --version base_os 3.17.3-at.6.20230612.1 \
--preserve-attributes baseos-x2-3.17.3-at.6.20230612.tar.zst
swdesc_boot imx-boot_armadillo_x2.signed ←★不要？
atmark@atde9:~/ $HOME/mkswu/mkswu/mkswu encrypted_rootfs_linux_update.desc enable_disk_encryption.desc encrypted_imxboot_update.desc OS_enc.desc -o OS_enc.swu> ちなみに今更ですが、セキュリティガイドの確認でカーネルのモジュールをインストールしていないことに気づきました。https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro… の「ビルドしたカーネルは、以下に示すどちらかの方法でインストールしてください」の二つ目の make ... modules_install を行わないと不具合が出ると思いますので、お手数ですがしてなかったら baseos のアーカイブを更新してください。（今回の問題には関係ないですが…）
「セキュリティガイド 5.7.4. 署名済み Linux カーネルイメージの作成」の前に実施すればよいでしょうか？
ご確認よろしくお願いいたします。
at_dominique.m…
gt777さん
> 「セキュリティガイド 5.7. ストレージの暗号化のセットアップ」のようにinitial_setup_encryption.swuを作成するのではなく、直接OS_enc.swuに暗号化用カーネル（swdesc_boot_linux) + 暗号化済み u-boot (swdesc_boot_enc) + ディスク暗号化変数を入れるということでしょうか？
セキュリティガイドの initial_setup_encryption は SD ですでにセキュアーブートを有効にした場合でいいんですが、今回は initial_setup をすでにセキュアーブートのためにインストールしましたので、暗号化用のイメージに initial_setup を入れてもインストールできなくなります。
内容は同じで、initial_setup だけのないイメージでいいはずです。
> atmark@atde9:~/build-rootfs-v3.17-at.6$ cat OS_enc.desc > swdesc_tar --version base_os 3.17.3-at.6.20230612.1 \ > --preserve-attributes baseos-x2-3.17.3-at.6.20230612.tar.zst > swdesc_boot imx-boot_armadillo_x2.signed ←★不要？ > > atmark@atde9:~/ $HOME/mkswu/mkswu/mkswu encrypted_rootfs_linux_update.desc enable_disk_encryption.desc encrypted_imxboot_update.desc OS_enc.desc -o OS_enc.swu
swdesc_boot は不要ですね。swdesc_boot か swdesc_boot_enc 一つしかインストールできませんので、両方を同じ swu に組み込むとどこかでエラーすると思います（考えてなかったパターンなので、descファイルを入れた順番によって起動できたり、インストールの後に再起動できないだけかもしれません… mkswu時のチェックを追加しておきます）
base_os の更新も暗号化の流れで不要ですが、今回はモジュールの追加もありますので残していいです。
> > ちなみに今更ですが、セキュリティガイドの確認でカーネルのモジュールをインストールしていないことに気づきました。https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro… の「ビルドしたカーネルは、以下に示すどちらかの方法でインストールしてください」の二つ目の make ... modules_install を行わないと不具合が出ると思いますので、お手数ですがしてなかったら baseos のアーカイブを更新してください。（今回の問題には関係ないですが…）
>
> 「セキュリティガイド 5.7.4. 署名済み Linux カーネルイメージの作成」の前に実施すればよいでしょうか？
暗号化の場合は前後でも問題ありません。
ディスク暗号化の場合は rootfs 上の /boot/Image や /boot/*.dtb, dtbo ファイルが使われてないので、そこにあるカーネルの証明があってもなくてもいいです。
（暗号化がない場合は /boot/Image が使われてますので、モジュールのインストールの後に証明済みの Image を /boot/Image にコピーする必要がありますので、5.7.4 の前でいいと思います。）
よろしくお願いします。
gt777
マルティネさん
何度もすみません。
> 内容は同じで、initial_setup だけのないイメージでいいはずです。
atmark@atde9:~/mkswu$ $HOME/mkswu/mkswu/mkswu encrypted_rootfs_linux_update.desc enable_disk_encryption.desc encrypted_imxboot_update.desc -o initial_setup_encryption.swu
→initial_setup.descを抜いてinitial_setup_encryption.swuを作成
atmark@atde9:~/build-rootfs-v3.17-at.6$ cat OS_enc.desc
swdesc_tar --version base_os 3.17.3-at.6.20230612.1 \
--preserve-attributes baseos-x2-3.17.3-at.6.20230612.tar.zst
atmark@atde9:~/build-rootfs-v3.17-at.6$ mkswu OS_enc.desc
→swdesc_bootを削除してOS_enc.swuを作成SWUを作り直してみましたが、やはり暗号化がされていないようです。
何度も申し訳ありませんが、原因についてご確認いただけますでしょうか。
| ファイル | ファイルの説明 |
|---|---|
| ストレージ暗号化適用2.log |
at_dominique.m…
gt777さん
> SWUを作り直してみましたが、やはり暗号化がされていないようです。
ログでは新しくした「initial_setup_encryption.swu」をインストールしなかったように見えますが、そのインストールを試しましたか？
その前の返事で OS_enc.desc を他の desc ファイルに合わせて一つの swu にしていましたが、ここで別けた理由が分かりません。別けても問題ないですが、暗号化を有効にする swu をインストールしてください。
その（initial_setup と関係なくなった）「initial_setup_encryption.swu」のインストールにエラーがあればみてみます。
よろしくお願いします
gt777
マルティネさん
セキュリティガイドでは「initial_setup_encryption.swu」をbuild-rootfs-[VERSION]/ax2/installerにコピーする手順に見えたのでその通りに作成しました。
atmark@atde9:~/mkswu$ $HOME/mkswu/mkswu/mkswu encrypted_rootfs_linux_update.desc \
enable_disk_encryption.desc encrypted_imxboot_update.desc -o initial_setup_encryption.swu ★initial_setup.descを抜いてinitial_setup_encryption.swu作成
atmark@atde9:~$ cp secureboot/Image.signed build-rootfs-v3.17-at.6/ax2/resources/boot/Image
atmark@atde9:~$ cp mkswu/initial_setup_encryption.swu build-rootfs-v3.17-at.6/ax2/installer ★initial_setup_encryption.swuをコピー
atmark@atde9:~/build-rootfs-v3.17-at.6$ sudo ./build_rootfs.sh --cache ../baseos-x2-3.17.3-at.6.cache.tar
atmark@atde9:~/build-rootfs-v3.17-at.6$ cat OS_enc.desc
swdesc_tar --version base_os 3.17.3-at.6.20230612.1 \
--preserve-attributes baseos-x2-3.17.3-at.6.20230612.tar.zst
atmark@atde9:~/build-rootfs-v3.17-at.6$ mkswu OS_enc.desc「initial_setup_encryption.swu」を作成せずに直接「OS_enc.desc」に組み込んだ場合はSWUpdate自体がエラーとなりました。
atmark@atde9:~/build-rootfs-v3.17-at.6$ $HOME/mkswu/mkswu/mkswu ../mkswu/encrypted_rootfs_linux_update.desc \ ../mkswu/enable_disk_encryption.desc ../mkswu/encrypted_imxboot_update.desc OS_enc.desc -o OS_enc.swu
armadillo:~# swupdate -d '-u https://(server)/OS_enc.swu' SWUpdate v2022.12_git20230414-r0 Licensed under GPLv2. See source distribution for detailed copyright notices. [INFO ] : SWUPDATE running : [main] : Running on AGX4500 Revision at1 [INFO ] : SWUPDATE running : [channel_get_file] : Total download size is 80427 kB. [INFO ] : SWUPDATE started : Software Update started ! [INFO ] : SWUPDATE running : [install_single_image] : Installing pre_script [INFO ] : SWUPDATE running : [read_lines_notify] : Updating base os: copying swupdate_preserve_files [ERROR] : SWUPDATE failed [0] ERROR : ---------------------------------------------- [ERROR] : SWUPDATE failed [0] ERROR : /!\ Disk reencryption was requested, but swupdate runs in /var/tmp so we cannot do it [ERROR] : SWUPDATE failed [0] ERROR : /!\ Re-run with TMPDIR=/tmp swupdate ... to force installation [ERROR] : SWUPDATE failed [0] ERROR : ---------------------------------------------- [ERROR] : SWUPDATE failed [0] ERROR : Command failed: sh -c 'sh $1' -- /var/tmp//scripts_pre.sh.zst.enc [ERROR] : SWUPDATE failed [0] ERROR : Error streaming scripts_pre.sh.zst.enc [ERROR] : SWUPDATE failed [1] Image invalid or corrupted. Not installing ... [ERROR] : SWUPDATE failed [0] ERROR : Writing into SWUpdate IPC stream failed. [ERROR] : SWUPDATE failed [0] ERROR : Channel operation returned error (23): 'Failed writing received data to disk/application' [INFO ] : No SWUPDATE running : Waiting for requests... Child 1662(download) exited, status=1
at_dominique.m…
gt777さん
> セキュリティガイドでは「initial_setup_encryption.swu」をbuild-rootfs-[VERSION]/ax2/installerにコピーする手順に見えたのでその通りに作成しました。
これにいくつかの問題があります：
* (こちらの問題）更新が漏れました、インストールディスク用のディレクトリが ax2/installer -> ax2/image_installer になりました
* image_installer ディレクトリに SWU をコピーする場合はインストールディスクを作成して、インストールディスクをインストールする場合に展開されますが、今回はインストールディスクを使わないので影響ありません。そこの説明が足りてないですね。
* （これもこちらの問題…）インストールディスクにインストールされる SWU は当時再起動を挟んで完全にインストールされていましたが、今のバージョンでは証明確認の後に展開されるだけで暗号化の設定に影響がありません。インストールディスク自体に暗号化の設定ができますのでこれで問題ないですが、ドキュメンテーションを更新し忘れて大変失礼しました。
secure boot と暗号化の設定が分かりにくいので、この齟齬も含めて修正する予定です。
> 「initial_setup_encryption.swu」を作成せずに直接「OS_enc.desc」に組み込んだ場合はSWUpdate自体がエラーとなりました。
> [ERROR] : SWUPDATE failed [0] ERROR : /!\ Disk reencryption was requested, but swupdate runs in /var/tmp so we cannot do it > [ERROR] : SWUPDATE failed [0] ERROR : /!\ Re-run with TMPDIR=/tmp swupdate ... to force installation
すみません、この制限を忘れていました…が、エラーのとおりですね。swupdate が /var/tmp を使っていたら appfs の暗号化はできません（/var/tmp は appfs の一部です）。
エラーのとおりに TMPDIR=/tmp swupdate -d '-u https://(server)/OS_enc.swu' を実行すればインストールできると思います。
USB メモリでの自動インストールの場合もデフォルトの /var/tmp を使っていますので、自動作業が難しくなりますね。今のところは手動で実行していますが、結果的には製造のための自動更新を目指していますね？
少し考えさせてください。
よろしくオンがいします。
gt777
マルティネさん
補足ですが、途中でコンテナのインストールも試していたためatlogにログが残っています。（失敗していますが。。）
Jun 12 13:10:50 armadillo NOTICE swupdate: Installed update to /dev/mmcblk2p2: extra_os.app1: unset -> 1, app1: unset -> 1, extra_os.app2: unset -> 1, app2: unset -> 1
> USB メモリでの自動インストールの場合もデフォルトの /var/tmp を使っていますので、自動作業が難しくなりますね。今のところは手動で実行していますが、結果的には製造のための自動更新を目指していますね？
最終的には自動更新ができると嬉しいですが、直近は手動でも問題ありません。
gt777
マルティネさん
> ちなみに今更ですが、セキュリティガイドの確認でカーネルのモジュールをインストールしていないことに気づきました。https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro… の「ビルドしたカーネルは、以下に示すどちらかの方法でインストールしてください」の二つ目の make ... modules_install を行わないと不具合が出ると思いますので、お手数ですがしてなかったら baseos のアーカイブを更新してください。（今回の問題には関係ないですが…）
上記対応をしたbaseosを組み込んだあたりから、無線用のネットワークIFを認識しなくなっているのですが、
元に戻す方法はありますでしょうか。
■現在
armadillo:~# nmcli d s DEVICE TYPE STATE CONNECTION eth0 ethernet connected Wired connection 1 eth1 ethernet unavailable -- lo loopback unmanaged --
■今朝（baseos変更前）
armadillo:~# nmcli d s DEVICE TYPE STATE CONNECTION eth0 ethernet disconnected -- mlan0 wifi disconnected -- eth1 ethernet unavailable -- lo loopback unmanaged -- uap0 wifi unmanaged -- p2p-dev-mlan0 wifi-p2p unmanaged --
gt777
マルティネさん
TMPDIR=/tmp swupdate -d '-u https://(server)/OS_enc.swu'を実施してみたところ、
一部エラーが出ておりディスクが正常に読み込めていないように見えております。
お手数ですが正常な状態かご確認いただけないでしょうか。
| ファイル | ファイルの説明 |
|---|---|
| ストレージ暗号化適用3.log |
at_dominique.m…
gt777さん
> TMPDIR=/tmp swupdate -d '-u https://(server)/OS_enc.swu'を実施してみたところ、
> 一部エラーが出ておりディスクが正常に読み込めていないように見えております。
> お手数ですが正常な状態かご確認いただけないでしょうか。
すみません、これも更新で誤りを入れました：
> ## Error: illegal character '='in variable name "upgrade_available=1"
/boot/uboot_env.d/00_defaults の「setenv upgrade_available=1」が「setenv upgrade_available 1」に変更しないといけないですね。
お手数ですが、build-rootfs の ax2/resources/boot/uboot_env.d/00_defaults で直してください。Armadillo で直す場合は 「fw_setenv -s /boot/uboot_env.d/00_defaults」で適用できます。
エラーの位置としては無事に暗号化済みの u-boot を更新できたので、abos-ctrl rollback && reboot で暗号化された OS に入ります。
よろしくお願いします。
at_dominique.m…
gt777さん
> 上記対応をしたbaseosを組み込んだあたりから、無線用のネットワークIFを認識しなくなっているのですが、
> 元に戻す方法はありますでしょうか。
まず、元に戻る方法です：
再び別の swu をまだインストールしなかった場合は「abos-ctrl rollback && reboot」でB面に戻れますので、一般的にいい方法です。
無線LANはまさにモジュールを使っていますので、モジュールとカーネルのバージョンが一致しません。
今まで動いていたのは、まだ baseos の linux-at-x2 パッケージで起動していたと思います。提供していただいたログでは 5.10.180-0-at カーネルを起動していたので、localversion で同じ -0-at" を設定してなければそうなりますね。
このカーネルは close 処理の後に起動できないと思っていましたがこちらで確認します…が、おそらく /boot/Image を更新してないだけだと思います。
ディスク暗号化が有効になったら使われなくなりますので、モジュールが無事にインストールされたらその時に直ります。インストールされた Armadillo に /lib/modules/[uname -r] のディレクトリにモジュールが入ってるはずです。
よろしくお願いします。
gt777
マルティネさん
>お手数ですが、build-rootfs の ax2/resources/boot/uboot_env.d/00_defaults で直してください。
こちらを修正したSWUイメージのインストールに失敗したので、Armadillo上で 「fw_setenv -s /boot/uboot_env.d/00_defaults」「abos-ctrl rollback && reboot 」を投入したところ、Armadilloの電源が入らなくなってしまいました。
ここから復旧させることは可能でしょうか。
| ファイル | ファイルの説明 |
|---|---|
| ストレージ暗号化適用4.log |
at_dominique.m…
gt777さん
> >お手数ですが、build-rootfs の ax2/resources/boot/uboot_env.d/00_defaults で直してください。
> こちらを修正したSWUイメージのインストールに失敗したので、Armadillo上で 「fw_setenv -s /boot/uboot_env.d/00_defaults」「abos-ctrl rollback && reboot 」を投入したところ、Armadilloの電源が入らなくなってしまいました。
> ここから復旧させることは可能でしょうか。
反応しなくなったのは u-boot の暗号化か証明の問題だと思います。「ストレージ暗号化適用3.log」の後の状態は大丈夫だったと思いますが、再び swupdate を実行してエラーの後に rollback したのは危ないと思います。
復旧は SD ブートしかないですので、お手数ですが build_image.sh で SD カード用のイメージを作成して起動させてください。
build_image.sh の --boot 引数に imx-boot_armadillo_x2.signed を使って、イメージに証明済みのカーネルが入っていたら起動できるはずです。（そこまで swu で行ってすみませんが、インストーラーまで作成した方が復帰しやすいと思います。
インストーラーでない場合は SD の u-boot の prompt で mmc partconf 2 0 2 0 で起動していた mmcblk2p2 に戻ります）
お手数ですが、よろしくお願いします。
gt777
gt777
マルティネさん
ストレージ暗号化の手順でイメージを作成し、SDブートを試したのですが、エラーとなっております。
度々申し訳ありませんが、原因についてわかりますでしょうか。
セキュリティガイド5.7. ストレージの暗号化のセットアップの手順で作成した「baseos-[VERSION].[DATE]-installer.img」を、
DD for WindowsというソフトでSDカードに書き込みしたものを使用しています。
| ファイル | ファイルの説明 |
|---|---|
| SDboot.log |
at_dominique.m…
gt777さん
マルティネです。
> ストレージ暗号化の手順でイメージを作成し、SDブートを試したのですが、エラーとなっております。
> 度々申し訳ありませんが、原因についてわかりますでしょうか。
「[2023-06-13 08:10:28.547] Could not find root= in cmdline or '/dev/mmcblk1p1' does not exist」と言うのは linux が SD カードを認識してくれないと言うエラーです。
「MDIO device at address 0 is missing」がその認識されてない原因のエラーですが、「見つからない」以外の情報がなくあまり参考にならないエラーですね…
u-boot から読めましたので、ハードウェアの適合性の問題ではなく、ドライバの設定の何か（カードが dts で設定しているスピードを対応してないなど）が問題になっていると思いますが、こういう調整が手探りしかできませんので時間かかりますし、確実でもありません。
対策として別の SD カードを試していただいた方が早いと思いますが、可能でしょうか？
これはセキュアーブートと関係なく、カーネルも無事に起動できたのでもうすぐに設定ができると思います。
こちらで installer のディスク暗号化設定を試して、無事に動いていますので、u-boot の環境変数の誤りで大変ご迷惑をかけしましたができそうです。
よろしくお願いします
gt777
at_dominique.m…
gt777さん
> > 対策として別の SD カードを試していただいた方が早いと思いますが、可能でしょうか？
> SDカードのすぐの手配が難しいため、別の手段があればそちらを試したいのですが、何かありますでしょうか。
> ここから昨日の状態に切り戻して、SWUpdateでの適用を続ける、等可能でしょうか？
そうですね、別のカードがなければそのカードの u-boot からブートパーティションを選びなおして、昨日の状態のシステムに戻れます。
SDカードに起動する際に「Hit any key to stop autoboot:」のメッセージでスペースなどを入力して「u-boot=>」のプロンプトになります。
そこで「mmc partconf 2 0 2 0」を入力して（反応のメッセージ無し）、電源を落としてから SDブートの JP1 を外して、再び起動すれば前の状態に戻ったはずです。
（ログでは /dev/mmcblk2p2 に起動していたので、おそらくその値であっていますが、ダメでしたら「mmc partconf 2 0 1 0」も試してください）
linux に戻れたら：
1/ fw_printenv update_encrypted_boot で「setenv upgrade_available 1 」 になったことを確認してください
2/ 昨日と同じ OS_enc.swu をインストールしてみてください
変数をなおしたことで無事に切り替えできるはずです。
> 同じSDカードに初期化用のインストールディスクを書き込み、もう1台のArmadillo（暗号化なし）でSDブートしたところ、問題なく初期化できましたので、SDカード自体は問題ないのかな、とも思っています。
すみません、そこは気になりますが少し後回しにしたいと思います。linux に戻れたら、SD カードのスピードの設定などを試せますので、まだ必要と感じたら別のスレッドで対応します。
よろしくお願いします。
gt777
マルティネさん
> SDカードに起動する際に「Hit any key to stop autoboot:」のメッセージでスペースなどを入力して「u-boot=>」のプロンプトになります。
> そこで「mmc partconf 2 0 2 0」を入力して（反応のメッセージ無し）、電源を落としてから SDブートの JP1 を外して、再び起動すれば前の状態に戻ったはずです。
> （ログでは /dev/mmcblk2p2 に起動していたので、おそらくその値であっていますが、ダメでしたら「mmc partconf 2 0 1 0」も試してください）
ありがとうございます。「mmc partconf 2 0 1 0」で戻れました。
> linux に戻れたら：
> 1/ fw_printenv update_encrypted_boot で「setenv upgrade_available 1 」 になったことを確認してください
→「setenv upgrade_available 1 」 になっておらず、「setenv upgrade_available=1 」 のままでした。
Armadillo上で「/boot/uboot_env.d/00_defaults」の値の修正ができていなかったようです。
修正して「fw_setenv -s /boot/uboot_env.d/00_defaults」で反映させ、2/のOS_enc.descをインストールしようとしたところ、エラーとなりました。
SWUpdate前に何か追加の手順が必要でしょうか？
armadillo:~# fw_printenv update_encrypted_boot Environment OK, copy 1 (略) && setenv upgrade_available=1 &&(略) armadillo:~# vi /boot/uboot_env.d/00_defaults armadillo:~# fw_setenv -s /boot/uboot_env.d/00_defaults Environment OK, copy 1 armadillo:~# fw_printenv update_encrypted_boot Environment OK, copy 0 (略) && setenv upgrade_available 1 && (略) armadillo:~# swupdate -d '-u https://(server)/OS_enc.swu' SWUpdate v2022.12_git20230414-r0 Licensed under GPLv2. See source distribution for detailed copyright notices. [INFO ] : SWUPDATE running : [main] : Running on AGX4500 Revision at1 [INFO ] : SWUPDATE running : [channel_get_file] : Total download size is 80427 kB. [INFO ] : SWUPDATE started : Software Update started ! [INFO ] : SWUPDATE running : [install_single_image] : Installing pre_script [INFO ] : SWUPDATE running : [read_lines_notify] : Updating base os: copying swupdate_preserve_files [ERROR] : SWUPDATE failed [0] ERROR : ---------------------------------------------- [ERROR] : SWUPDATE failed [0] ERROR : /!\ Could not find appfs source device [ERROR] : SWUPDATE failed [0] ERROR : ---------------------------------------------- [ERROR] : SWUPDATE failed [0] ERROR : Command failed: sh -c 'sh $1' -- /var/tmp//scripts_pre.sh.zst.enc [ERROR] : SWUPDATE failed [0] ERROR : Error streaming scripts_pre.sh.zst.enc [ERROR] : SWUPDATE failed [0] ERROR : Writing into SWUpdate IPC stream failed. [ERROR] : SWUPDATE failed [1] Image invalid or corrupted. Not installing ... [ERROR] : SWUPDATE failed [0] ERROR : Channel operation returned error (23): 'Failed writing received data to disk/application' [INFO ] : No SWUPDATE running : Waiting for requests... Child 1966(download) exited, status=1 armadillo:~#
gt777
マルティネさん
すみません、TMPDIRの対処を忘れていたのでコマンド打ち直してみましたが、変わらずエラーとなりました。
お手数ですがご確認お願いいたします。
armadillo:~# TMPDIR=/tmp swupdate -d '-u https://(server)/OS_enc.swu' SWUpdate v2022.12_git20230414-r0 Licensed under GPLv2. See source distribution for detailed copyright notices. [INFO ] : SWUPDATE running : [main] : Running on AGX4500 Revision at1 [INFO ] : SWUPDATE running : [channel_get_file] : Total download size is 80427 kB. [INFO ] : SWUPDATE started : Software Update started ! [INFO ] : SWUPDATE running : [install_single_image] : Installing pre_script [INFO ] : SWUPDATE running : [read_lines_notify] : Updating base os: copying swupdate_preserve_files [ERROR] : SWUPDATE failed [0] ERROR : ---------------------------------------------- [ERROR] : SWUPDATE failed [0] ERROR : /!\ Could not find appfs source device [ERROR] : SWUPDATE failed [0] ERROR : ---------------------------------------------- [ERROR] : SWUPDATE failed [0] ERROR : Command failed: sh -c 'sh $1' -- /tmp//scripts_pre.sh.zst.enc [ERROR] : SWUPDATE failed [0] ERROR : Error streaming scripts_pre.sh.zst.enc [ERROR] : SWUPDATE failed [1] Image invalid or corrupted. Not installing ... [ERROR] : SWUPDATE failed [0] ERROR : Writing into SWUpdate IPC stream failed. [ERROR] : SWUPDATE failed [0] ERROR : Channel operation returned error (23): 'Failed writing received data to disk/application' [INFO ] : No SWUPDATE running : Waiting for requests... Child 2240(download) exited, status=1
at_dominique.m…
gt777さん、
> すみません、TMPDIRの対処を忘れていたのでコマンド打ち直してみましたが、変わらずエラーとなりました。
> お手数ですがご確認お願いいたします。
あ、ディスク暗号化が有効にされましたので、インストール前の状態に戻っても正常に動きません…
すみません、忘れていました。(昨日のログにワーニングで注意がありましたね：
WARNING: Reformatting appfs with encryption, current container images and WARNING: volumes will be lost. Also, in case of update failure or rollback WARNING: current system will not be able to mount it
)
そこは swupdate のスクリプトで再作成できるようにしたいところですが、手動で appfs をマウントした方が早いと思います。
こちらで再現して、最低限の手順を用意しますのでちょっとお待ちください。
at_dominique.m…
gt777さん、
>> すみません、TMPDIRの対処を忘れていたのでコマンド打ち直してみましたが、変わらずエラーとなりました。
>> お手数ですがご確認お願いいたします。
>
> そこは swupdate のスクリプトで再作成できるようにしたいところですが、手動で appfs をマウントした方が早いと思います。
> こちらで再現して、最低限の手順を用意しますのでちょっとお待ちください。
おまたせしました。
fstab の変更だけですので、以下のコマンドで対応できます：
# 修正： 暗号化されているパーティションをマウントさせるように、 /dev/mmcblk2p5 を /dev/mapper/mmcblk2p5 にします。
armadillo:~# sed -i -e 's:mmcblk2p[35]:mapper/&:' /etc/fstab
armadillo:~# mount -a
mount: /var/lib/containers/storage_readonly: mount(2) system call failed: No such file or directory.
dmesg(1) may have more information after failed mount system call.
mount: /var/app/rollback/volumes: mount(2) system call failed: No such file or directory.
dmesg(1) may have more information after failed mount system call.
# そこで /var/lib/containers/storage_readonly と /var/app/rollback/volumes をマウントできなかったエラーがありますが、無視してください。
# 確認として、lsblk で /var/tmp 等が暗号化されてマウントせれているはずです：
armadillo:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk2 179:0 0 7.3G 0 disk
├─mmcblk2p1 179:1 0 300M 0 part /live/rootfs
├─mmcblk2p2 179:2 0 300M 0 part
├─mmcblk2p3 179:3 0 50M 0 part
│ └─mmcblk2p3 253:0 0 49M 0 crypt /var/log
├─mmcblk2p4 179:4 0 200M 0 part /opt/firmware
└─mmcblk2p5 179:5 0 6.5G 0 part
└─mmcblk2p5 253:1 0 6.5G 0 crypt /var/tmp ★ここ
/var/app/volumes
(省略)
# 新しい fstab を保存して、インストール先にも修正済みの fstab を使います
armadillo:~# persist_file -v /etc/fstab
'/etc/fstab' -> '/mnt/etc/fstab'
# すでに暗号化されていますので、TMPDIR の変数は不要です
armadillo:~# swupdate -d '-u ...OS_enc.swu'よろしくお願いします。
gt777
gt777
at_dominique.m…
gt777さん
> fstabを修正してSWUpdateしたところ、インストールはできましたが、再起動後立ち上がってこなくなってしまいました。
> (LED4は点灯しています）
> ログを添付しますのでお手数ですがご確認をお願いいたします。
このログでは異常はまったくないですね…反応しなくなったリセットまで、こちらで試した SWU と同じですので、情報がもう少し必要になります。以下に聞きます。
> また、ここからの復帰は、再度SDブートでu-bootからロールバックが必要でしょうか。
はい、暗号化された u-boot の問題の場合は SD ブートでしかロールバックできません。
暗号化されてない u-boot の証明の問題の場合は B面の u-boot で起動します（それもそれで確認できなくて困っています…ログで hab のエラーが表示されますが、linuxに入ったらインストールが成功したように見えますので、次の更新で起動できなくなるリスクはあります）
なので、セキュアーブートのアップデートは必ず手元の開発機で確認してから運用のデバイスに提供してください。開発機で確認できたら、OTAアップデートでも問題ないはずです。
これからの対応：
1/ SD カードで復帰して、「encrypted_imxboot_update」をはずしてディスク暗号化だけを終わらせたいと思います。（mkswu コマンドからその desc ファイルをはずして、念のため swdesc_boot imx-boot_armadillo_x2.signed を OS_enc.desc に戻してください。
インストールした内容の組み合わせに問題がないはずですが、内容が少ない方が確認しやすいですので。
2/ そのあと、暗号化 u-boot の手順だけを頭から作り直しましょう：
ATDEから: # 最低限の依存 $ sudo apt install python3-pycryptodome python3-pyelftools # imx-boot-2020.04-at14 の展開、secureboot.conf の設定... # 現在の cst-3.3.1 ディレクトリに必要な鍵がありますので大事に保存してください。 $ cd /home/atmark/imx-boot-2020.04-at14 [imx-boot ディレクトリ]$ ./secureboot.sh imxboot_enc ... offset for dek_spl_blob: 0x26200 offset for dek_fit_blob: 0x34b890 Created /home/atde/imx-boot-[version]/../secureboot/imx-boot_armadillo_x2.enc [swuファイルを保存するディレクトリ]$ cat encrypted_imxboot_update.desc swdesc_option version=3 swdesc_boot_enc $HOME/secureboot/imx-boot_armadillo_x2.enc $HOME/secureboot/armadillo_x2.dek_offsets [swuファイルを保存するディレクトリ]$ $HOME/mkswu/mkswu/mkswu encrypted_imxboot_update.desc uboot_enc.swu を作成しました。 armadillo: その uboot_enc.swu のインストール。
これはすでに行った手順と同じだと思いますのであまり期待はしていませんが、一通り行っていただいたら嬉しいです。
3/ 2/ が失敗した場合に、2/ のログと、以下の内応のログをお願いします：
# armadillo, 修正したバグあったところ以外の確認 $ fw_printenv update_encrypted_boot # atde側 $ cat $HOME/secureboot/armadillo_x2.dek_offsets dek_spl_offset 0x26200 dek_fit_offset 0x34b890 ^ のアドレスに合わせて $ dd if=$HOME/secureboot/imx-boot_armadillo_x2.enc bs=64 count=1 skip=$((0x26200)) iflag=skip_bytes | xxd $ dd if=$HOME/secureboot/imx-boot_armadillo_x2.enc bs=64 count=1 skip=$((0x34b890)) iflag=skip_bytes | xxd
の提供をお願いします。
お手数ですが、よろしくお願いします。
gt777
マルティネさん
SDブートのロールバックは完了しましたが、
1/ の手順でSWUpdateがエラーとなってしまいました。
何度もすみませんが、ご確認いただけないでしょうか。
使用したファイルは以下です。
atmark@atde9:~/build-rootfs-v3.17-at.6$ mkswu --show OS_enc_2.swu # OS_enc_2.swu # built with mkswu 4.12-2-g3e71269 swdesc_option ENCRYPT_ROOTFS swdesc_option ENCRYPT_USERFS swdesc_tar --version base_os 3.17.3-at.6.20230612.4 --preserve-attributes baseos-x2-3.17.3-at.6.20230612.tar.zst # (encrypted) swdesc_boot_linux --version boot_linux 2 ../secureboot/Image.signed # (encrypted) swdesc_command --version extra_os.disk_encryption 1 true swdesc_boot --install-if different --version boot 2020.4-at14 ../secureboot/imx-boot_armadillo_x2.signed # (encrypted)
SDブートでの起動時に「*** Warning - bad CRC, using default environment」という警告が出ていたのが気になりました。
（データが破損している？）
| ファイル | ファイルの説明 |
|---|---|
| ストレージ暗号化適用6.log |
at_dominique.m…
[INFO ] : SWUPDATE running : [install_single_image] : Installing swdesc_tar --version base_os 3.17.3-at.6.20230612.4 --preserve-attributes baseos-x2-3.17.3-at.6.20230612.tar.zst [INFO ] : SWUPDATE running : [install_single_image] : Installing swdesc_boot_linux ../secureboot/Image.signed [INFO ] : SWUPDATE running : [install_single_image] : Installing swdesc_command true ... [ERROR] : SWUPDATE failed [0] ERROR : ---------------------------------------------- [ERROR] : SWUPDATE failed [0] ERROR : /!\ Installed u-boot does not appear to be for aarch64, aborting! [ERROR] : SWUPDATE failed [0] ERROR : /!\ In case of false positive, set MKSWU_NO_ARCH_CHECK=1 $ mkswu --show ...swu swdesc_boot --install-if different --version boot 2020.4-at14 ../secureboot/imx-boot_armadillo_x2.signed
このチェックがここで発生するのは今後の swdesc_boot_linux の更新として少し見直さないといけない※ですが、今回は助かりました。そのエラーが正しいです、今の状態で再起動しても起動できなくなります。
今の B面に壊れた暗号化されている u-boot だけですが、入れていただいた swdesc_boot のバージョンが現在のバージョンと一致するためインストールされませんでした。(swupdate ログに「installing swdesc_boot ...」がありませんでした）
swdesc_boot_enc 同様に、swdesc_boot の前に swdesc_option version=何かでバージョンを固定してインストールさせてください。
※ 暗号化された u-boot が正常に動いて、カーネルだけの更新の場合は今のバージョンではエラーしますが、エラーしないようになおしますので今後のアップデートでこのエラーは消えます。
普通の流れとして、以下の用にコピーで自動的に更新されます：
* A面起動中
* u-boot を含むswu のインストールで B面の u-boot の更新
* 次の (同じu-bootか u-boot 無し）swuのインストールで B面の u-boot が A面にコピーされます
* それ以降の（u-boot無し）swuのインストールで u-boot をコピーしません。
が、今回は rollback でB面の u-boot 状態 が把握してないためコピーもされませんでした。
これも不具合の類だと思っていますので、rollback の後でも必要な場合にコピーするようにしますが、今はバージョンを設定してください。
> SDブートでの起動時に「*** Warning - bad CRC, using default environment」という警告が出ていたのが気になりました。
> （データが破損している？）
これは少し汚いですが、SDカードに環境変数を保存していないため毎回デフォルトの変数で起動します。無視していいです。
よろしくお願いします
gt777
マルティネさん
ご指摘通り、swdesc_bootにバージョンを付与したところ、無事にSWUpdateが完了し、
lsblkコマンドでも暗号化されたことが確認できました。ありがとうございます！
atmark@atde9:~/build-rootfs-v3.17-at.6$ mkswu --show OS_enc_3.swu # OS_enc_3.swu (略) swdesc_boot --install-if different --version boot 2 ../secureboot/imx-boot_armadillo_x2.signed # (encrypted)
この後は2023年6月13日 13時02分のコメントでいただいた2/の手順を実施する、で良いでしょうか？
> 2/ そのあと、暗号化 u-boot の手順だけを頭から作り直しましょう：
>
> ATDEから: > # 最低限の依存 > $ sudo apt install python3-pycryptodome python3-pyelftools > # imx-boot-2020.04-at14 の展開、secureboot.conf の設定... > # 現在の cst-3.3.1 ディレクトリに必要な鍵がありますので大事に保存してください。 > $ cd /home/atmark/imx-boot-2020.04-at14 > [imx-boot ディレクトリ]$ ./secureboot.sh imxboot_enc > ... > offset for dek_spl_blob: 0x26200 > offset for dek_fit_blob: 0x34b890 > Created /home/atde/imx-boot-[version]/../secureboot/imx-boot_armadillo_x2.enc > [swuファイルを保存するディレクトリ]$ cat encrypted_imxboot_update.desc > swdesc_option version=3 > swdesc_boot_enc $HOME/secureboot/imx-boot_armadillo_x2.enc $HOME/secureboot/armadillo_x2.dek_offsets > [swuファイルを保存するディレクトリ]$ $HOME/mkswu/mkswu/mkswu encrypted_imxboot_update.desc > uboot_enc.swu を作成しました。 > > armadillo: その uboot_enc.swu のインストール。 >
>
| ファイル | ファイルの説明 |
|---|---|
| ストレージ暗号化適用7.log | インストール成功ログ |
at_dominique.m…
gt777さん
> ご指摘通り、swdesc_bootにバージョンを付与したところ、無事にSWUpdateが完了し、
> lsblkコマンドでも暗号化されたことが確認できました。ありがとうございます！
大変でしたが、よかったです。
> この後は2023年6月13日 13時02分のコメントでいただいた2/の手順を実施する、で良いでしょうか？
u-boot の暗号化も必要と考えていたらそうですね、そのままでお願いします。
こちらの環境で動いていますので、個人的には故障の理由が気になっていますが、結局今日ほぼ一日の作業は imx-boot の暗号化更新の問題だけから始めた作業で、ブートイメージの暗号化のメリット / デメリットを改めて確認するいい機会だと思います。
よろしくお願いします。
gt777
マルティネさん
引き続きすみません。
2/の手順でubootの暗号化を試みているのですが、SWUpdate後にresettingが表示された後、正常に起動ができません。
SDブートでロールバックし、3/の情報を収集しましたので、お手数ですがご確認お願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| uboot_enc_エラー.log |
at_dominique.m…
gt777さん
> 2/の手順でubootの暗号化を試みているのですが、SWUpdate後にresettingが表示された後、正常に起動ができません。
> SDブートでロールバックし、3/の情報を収集しましたので、お手数ですがご確認お願いいたします。
ログありがとうございます。
とりあえず uboot での書き込みのコマンドはこちらと同じで問題ないはずですし、デバイス個別の鍵を直す offset も問題なさそうです。
2/ のビルドメッセージのログも提供いただけますでしょうか？鍵は表示されてませんので、共有しても大丈夫です。
以前提供していただいた「swupdateイメージ作成.log」に前のビルドの記録があって、気になるところがありましたのでそれを確認したいです。gt777さんのログでは以下の用になっていますが：
[2023-06-09 14:50:19.421] CSF Processed successfully and signed data available in /home/atmark/imx-boot-2020.04-at14/../secureboot/armadillo_x2.csf_spl_enc.bin [2023-06-09 14:50:19.442] CSF Processed successfully and signed data available in /home/atmark/imx-boot-2020.04-at14/../secureboot/armadillo_x2.csf_spl_sign_enc.bin [2023-06-09 14:50:19.447] copying csf_spl_enc.bin 2648 -> csf_spl_sign_enc.bin 2648 36 bytes [2023-06-09 14:50:19.478] CSF Processed successfully and signed data available in /home/atmark/imx-boot-2020.04-at14/../secureboot/armadillo_x2.csf_fit_enc.bin [2023-06-09 14:50:19.534] CSF Processed successfully and signed data available in /home/atmark/imx-boot-2020.04-at14/../secureboot/armadillo_x2.csf_fit_sign_enc.bin
手元のビルドでメッセージが多いです：
Install SRK Install CSFK Authenticate CSF Install key Authenticate data CSF Processed successfully and signed data available in /home/atmark/imx-boot/../secureboot/armadillo_x2.csf_spl_enc.bin Install SRK Install CSFK Authenticate CSF Install key Authenticate data CSF Processed successfully and signed data available in /home/atmark/imx-boot/../secureboot/armadillo_x2.csf_spl_sign_enc.bin 省略
そのどれものメッセージは cst ツールの出力なので、成功していると出力されていますが、その違いで実は処理に問題がある可能性があります。
試しに以下のコマンドを実行していただけますか？
(ATDE側） $ cd ~/secureboot $ ../cst-3.3.1/linux64/bin/cst -i armadillo_x2.csf_spl_enc.txt -o test Install SRK Install CSFK Authenticate CSF Install key Authenticate data CSF Processed successfully and signed data available in test $ echo $? $ rm -f test
また、secureboot ディレクトリの armadillo_x2.csf*.txt ファイルの内容も添付していただけたら助かります。そんなに大きくないので、cat で表示してターミナルの出力で構いません。
これでも問題がなければインストール直後の uboot シェルでさらにいくつかの確認ができるはずですが、準備に時間かかりますのでその確認からお願いします。
よろしくお願いします。
at_dominique.m…
gt777
マルティネさん
> 2/ のビルドメッセージのログも提供いただけますでしょうか？鍵は表示されてませんので、共有しても大丈夫です。
本日再ビルドした際のログを添付します。
> 試しに以下のコマンドを実行していただけますか？
> また、secureboot ディレクトリの armadillo_x2.csf*.txt ファイルの内容も添付していただけたら助かります。そんなに大きくないので、cat で表示してターミナルの出力で構いません。
こちらも添付します。
すみません、大事なことを共有できていなかったことに気づきました。
CSTのツールですが、NXPのサイトから取得できたのが最新版の3.3.2のみで、3.3.1が見当たらなかったため、3.3.2を利用しております。
上手く動作しなかった部分を以下のように修正しました。
imx-boot-[VERSION]/secureboot.conf
CST="$SCRIPT_DIR/../cst-3.3.1" →「3.3.2」に修正
imx-boot-[VERSION]/secureboot.sh
./hab4_pki_tree.sh -existing-ca n -use-ecc "$CST_ECC" -kl "$CST_KEYLEN" \ →「-use-ecc "$CST_ECC"」を「-kt ecc」に修正
| ファイル | ファイルの説明 |
|---|---|
| 20230614_ビルドメッセージ.log | |
| 20230614_ armadillo_x2.csf関連.log |
gt777
gt777
at_dominique.m…
gt777さん、
> メールでご案内いただいた内容で、無事、暗号化u-bootのSWUpdateが完了しました。
> 長らくご対応いただいて本当にありがとうございました。
分かりにくく手順ですみません、できてよかったです。
こちらとしては、以下の課題を残しています：
- mkswu で問題あった場所を直しましたので（swdesc_boot_linuxだけの更新が失敗するなど）、今月にリリースします。
- cst 3.3.2 の対応は後ほど行いますが、今月のアップデートでセキュリティマニュアルに注意をたします。
- USB メモリでの swu 自動インストールでのディスク暗号化対応を課題にします。これも今月では修正しないと思いますが、できたらまた連絡します。今の状態では SRK fuse などのためにシリアル接続も必要になっていますので、実装を試してからまとめてリリースしたいと思います。
- これも先の話になりますが、自動化の部分を増やしてセキュリティガイドの内容を整理する予定です。
よろしくお願いします。
at_dominique.m…
2023年6月9日 12時28分
gt777さん、
お世話になっています、
マルティネです。
> セキュアブート（ストレージの暗号化）用イメージをインストールする方法について、
> SDブートではなくSWUpdateを利用することは可能でしょうか？
更新は swupdate でできますが、最初の SRK の設定だけは今のところ swupdate からのアップデートで実装していません。
（ちなみに SD ブートのイメージでも SRK 等 fuse の書き込み対応はしてないはずです。fuse 書き込み後の暗号化の対応だけがあります。自動化を実装するならどっちでも対応できますね。今の実装ではシリアルの接続がある BTO を使っていただく想定です。）
理由はいくつかあります：
- セキュアブートの設定は「危ない」（間違った設定を入力したら起動できなくなる可能性があります）ので、セキュリティガイドの様に u-boot シェルで fuse prog コマンドを入力させることでリスクを意識させます。
- linux から fuse の書き込みはできないので、普通のアップデートの流れと違いって u-boot を操作しないといけません。セキュアブート実装時でいくつかツールがいくつか足りてなかったが、今になっては対応できます。
- 順番を間違ったら正しい鍵でも、リモートの場合はアクセス不可能になる可能性があります。順番の疑問あったので、後で説明します。
- (勝ってで申し訳ございませんが、「まだ必要とされなかった」のもあります…）
> 「セキュリティガイド 5.7. ストレージの暗号化のセットアップ」を参考に「baseos-[VERSION].[DATE].tar.zst」を作成し、
> 「製品マニュアル 9.7.3. Alpine Linux ルートファイルシステムをビルドする」を参考に.swuイメージの作成まで実施したのですが、
> 「セキュリティガイド 5.8.2. SRK ハッシュの書き込み」とSWUpdateの順序関係がわからず先に進めていない状況です。
そうですね、実装としてとても分かりにくいと思いますが、NXP の設計であまり余裕がないです。
もっとも注意が必要な点はこの二つだと考えています：
- SRK は書いておいてもいいですが、close 処理を行った後はもちろん証明してない u-boot を起動できなくなりますので、u-boot/linux はまずアップデートする必要があります。
- 暗号化の場合は close 処理の際に暗号化の鍵がリセットされますので、close処理前に暗号化を行った場合に起動できなくなります（NXPからの理由は、closeされてない場合に暗号化の鍵が漏れる恐れがあるため、closeの際にリセットされます）
SD ブートでインストールする場合は SD ブートを無効にしない限り、SD にある u-boot/linux カーネルさえサインしておけば気にせず SRK を書いて、再起動して、暗号化された物をインストールできます。
Swupdate で書き込みした場合は、何回か更新する必要があります：
* 暗号化されてない、証明済みの u-boot/linux を書き込む
* それに切り替える
* その u-boot から SRK/close処理を行って、リセットする（リセットしないと適用されないのでご注意ください）
* 必要な場合に暗号化のためもう一度インストールしる
*（そこに切り替えた後に平文の rootfs を再び上書きする。マニュアルに紹介されてませんが、セキュアブートを使う場合は、インストールの後に動作確認を行って、大丈夫な場合に「abos-ctrl rollback-clone」で古い面を更新することを推奨します）
swupdate での設定はとても自動化しにくいですが、以下のやり方でできると思います：
* 一つ目の swu で証明済みの u-boot/kernel をインストールして、インストール先の /boot/boot.scr に SRK等の fuse を約処理を行います
* 二つ目の swu で暗号化を行って、自分のアプリケーションを転送します。暗号化は「ENCRYPT_ROOTFS」と「ENCRYPT_USERFS」の swdesc_option 変数で有効にできますが、マニュアルに説明がないですね…すみません。
両方の swu を同じ USB メモリに書き込まれた場合は alpha 純でインストールされますので、メモリを接続して自動的に二回再起動するだけです。
（alpha 純は保証しますが、swu のインストールの際に swdesc_command で現状確認をして間違った順番でインストールできないようにした方がいいですね…）
なので、できないことはないですが、実装する際に色々気をつけるべきところが多いので、時間の優先度の問題でまだ提供できそうな実装はしてません。
お手数ですが、すぐに必要でしたら個別で対応した方が早いかもしれません。
> また、SWUpdateが利用可能な場合、ストレージ暗号化の範囲指定（SD boot ディスク作成時の--encrypt allオプション）の指定方法も教えてください。
マニュアルに説明不足で申し訳ございません。
オプション名を先ほど書きましたが、実装されています：
- swdesc_option ENCRYPT_USERFS で build_image.sh の --encrypt userfs とほぼ同じ結果で、 /var/log と appfs が暗号化されます。
同じだと思っていましたが、ただいま確認して、SD インストーラーの場合は /opt/firmware も暗号化しますが、swupdate の場合に暗号化されません。app/log を swupdate で暗号化する際に完全にクリアされますが firmware を作り直す手段がないのは理由です。やろうと思えばどこかに一旦コピーして、暗号化してから戻すことは可能ですが、実装してません。
- swdesc_option ENCRYPT_ROOTFS で rootfs も暗号化します。 build_image.sh の --encrypt all と userfs の差だけです（両方を設定する必要があります）
両方のオプションを secure boot 無しで使用しても動きますが、暗号化の鍵に意味がないのでご了承ください。SRK/close 処理が行われた後に実行される想定です。
よろしくおねがいします。