セキュリティ

Armadillo は消費電力の削減のため SE050 を Deep Power-down モードに設定してパワーゲーティングしている。Deep Power-down モードを解除して SE050 を利用するためには、i.MX 8M Plus に接続されている SE050 の ENA ピンをアサートする必要があります。

gpioset コマンドを利用して GPIO1_IO12 を出力ポートに変更して high にする。

[armadillo ~]# persist_file -a add libgpiod
[armadillo ~]# gpioset gpiochip0 12=1

Linux を利用するシステムでは、自社開発したソフトウェアだけでなく複数の OSS が導入されるケースがあります。このような状況下では、自社開発したタスクだけでなく、同時にOSSのタスクが実行されることになり、システムのどこかに悪意のあるコードが含まれるのか、その可能性を排除することは困難です。仮にすべての OSS が信頼できるものであったとしても、不具合がないことを保証することはほぼ不可能であり、結局のところどのソフトウェアが脆弱性のきっかけになるかは分からないのです。

そういった背景から Arm は TrustZone 技術を導入しました。リソースアクセス制限によって敵対的なソフトウェアからソフトウェア実行環境を隔離することができます。TrustZone の導入によって、自社開発以外のソフトウェアが多数動作する状況においても、通常はセキュアワールドにその影響が及びません。TrustZone を利用したものとして、GlobalPlatform の TEE (Trusted Execution Environment) を実現するソフトウェアがいくつか存在します。TEE を活用すると secure world において信頼できるソフトウェアだけを実行させることが可能です。

では、どういったケースで TEE を採用するべきでしょうか。一概には言えませんが、情報資産とその資産を処理するライブラリなどをまとめて保護するケースで利用することが考えられます。具体的には、電子決済処理、証明書の処理、有料コンテンツの処理、個人情報の処理などで利用するケースが考えられます。

商用、OSS の TEE などいくつかの TEE 実装が存在します。Armadillo Base OS では OP-TEE を採用します。OSS である OP-TEE は Arm コア向け TEE 実装の1つです。Arm TrustZone テクノロジーによって情報資産とその処理をセキュアワールドに隔離して攻撃から保護します。OP-TEE は GlobalPlatform によって定義される TEE Client API や TEE Core API といった GlobalPlatformAPI に準拠したライブラリを提供しています。これらのAPI を利用することでユーザーはカスタムアプリケーションを開発することが可能です。imx-optee-xxx は NXP による i.MX ボートのサポート対応が含まれる OP-TEE の派生プロジェクトです。

	OP-TEE の詳しい情報は公式のドキュメントを参照してください。 OP-TEE documentation 　 https://optee.readthedocs.io/en/latest/

前節で説明した OP-TEE の主要なリポジトリを実際に Armdillo BaseOS に適用する場合、Armadillo Base OS とどのように関係するのか全体像を説明します。

以下が Armadillo Base OS との関係を表した全体像。

図11.2 Armadillo Base OS と OP-TEE の担当範囲

imx-optee-os を組み込む作業は煩雑です。ユーザーの手間を省くために Armadillo Base OS には常に imx-optee-os バイナリがブートローダーに組み込むように実装されています。工場出荷状態イメージや製品アップデート向け Armadillo Base OS イメージにも含まれます。しかし、セキュリティ上の懸念から OP-TEE が利用できる状態で組み込まれていません。詳しくは 「鍵の更新」 で説明します。

imx-optee-os リポジトリには TA を署名するためのデフォルトの秘密鍵が配置されています。その秘密鍵はあくまでテストや試行のためのものです。そのまま同じ秘密鍵を使い続けると、攻撃者がデフォルトの秘密鍵で署名した TA が動作する環境になってしまいます。各ユーザーが新しい鍵を用意する必要があります。

	生成した秘密鍵 (上記の rsa4096.pem) は TA を更新していくために、今後も利用するものです。壊れにくい、セキュアなストレージにコピーしておくことをお勧めします。

	鍵の更新は計画性を持って行ってください。たとえば開発時のみ利用する鍵、運用時に利用する鍵を使い分ける。また、鍵は定期的に更新が必要です。以下を参考にしてください。 BlueKrypt Cryptographic Key Length Recommendation 　 https://www.keylength.com/

	鍵の更新に関する詳しい情報は公式のドキュメントを参照してください。 Offline Signing of TAs 　 https://optee.readthedocs.io/en/latest/building/trusted_applications.html#offline-signing-of-tas

OP-TEE が含まれるブートローダーをビルドしていきます。Armadillo Base OS を利用した OP-TEE のビルドの流れは以下のとおりです。

本マニュアルで説明するビルド環境でのディレクトリ構成の概略は以下のとおりです。

optee_examples はユーザーアプリケーションを配置する場所です。本マニュアルでは Linaro が提供するアプリケーションのサンプルプログラムである optee_examples としました。本来は各ユーザーのアプリケーションを配置する場所になります。

├── imx-boot
│   ├── imx-atf
│   ├── imx-mkimage
│   ├── imx-optee-os
│   └── uboot-imx
├── imx-optee-client
├── imx-optee-test
├── optee_examples
└── out

「Armadilloのソフトウェアをビルドする」 の章を参考にしてビルド環境の構築からブートローダーのビルドまでを事前に行ってください。

imx-optee-test をビルドするために必要になります。

[PC ~]$ sudo apt install g++-aarch64-linux-gnu

新しい鍵を取り込むためにブートローダーを再ビルドする必要があります。

imx-optee-client は TA, CA が利用するライブラリ。アプリケーションをビルドする前にビルド必要がある。

	imx-optee-client は imx-optee-os のビルド結果を参照しているので、事前にブートローダーをビルドする必要があります。

本来はユーザーが独自に作ったアプリケーションをビルドしますが、ここでは参考までにサンプルアプリケーション optee_examples をビルドします。アプリケーション開発の参考にしてください。

	アプリケーションをビルドするためには imx-optee-os, imx-optee-client のビルド結果を参照しているので、一度は imx-boot, imx-optee-client をビルドする必要があります optee_examples にはインストールする make ターゲットがないので、ビルド後に手動で集める作業が必要があります

imx-optee-test は必ずしも必要ではありません。利用機会は限られますが、OP-TEE の基本動作を確認するため、パフォーマンスを計測するために imx-optee-test を利用することができます。組み込むかどうかの判断はお任せします。

	アプリケーションをビルドするためには imx-optee-os, imx-optee-client のビルド結果を参照しているので、一度は imx-boot, imx-optee-client をビルドする必要があります。

	本リリース時点では xtest 1014 にてエラーになる問題があります。そのため環境変数で CFLAGS=-O2 を渡しています。make 引数で渡すとヘッダファイルの include 設定がなくなります。 ブートローダーのビルド時に O2 としているのも同様の理由です。 NXP LS Platforms: pkcs_1014 test is failing #4909 　 https://github.com/OP-TEE/optee_os/issues/4909

imx-optee-os, imx-optee-client の最小構成では以下のとおりです。

out/
|-- lib
|   `-- optee_armtz 
|       |-- 023f8f1a-292a-432b-8fc4-de8471358067.ta
|       |-- f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.ta
|       `-- fd02c9da-306c-48c7-a49c-bbd827ae86ee.ta
`-- usr
    |-- include
    |   |-- ck_debug.h
    |   |-- optee_client_config.mk
    |   |-- pkcs11.h
    |   |-- pkcs11_ta.h
    |   |-- tee_bench.h
    |   |-- tee_client_api.h
    |   |-- tee_client_api_extensions.h
    |   |-- tee_plugin_method.h
    |   `-- teec_trace.h
    |-- lib 
    |   |-- libckteec.a
    |   |-- libckteec.so -> libckteec.so.0
    |   |-- libckteec.so.0 -> libckteec.so.0.1
    |   |-- libckteec.so.0.1 -> libckteec.so.0.1.0
    |   |-- libckteec.so.0.1.0
    |   |-- libteec.a
    |   |-- libteec.so -> libteec.so.1
    |   |-- libteec.so.1 -> libteec.so.1.0.0
    |   |-- libteec.so.1.0 -> libteec.so.1.0.0
    |   `-- libteec.so.1.0.0
    `-- sbin 
        `-- tee-supplicant

imx-optee-test, optee_examples を含めたビルド結果は以下のとおりです。

out
|-- bin
|   `-- xtest
|-- lib
|   `-- optee_armtz
|       |-- 023f8f1a-292a-432b-8fc4-de8471358067.ta
|       |-- 2a287631-de1b-4fdd-a55c-b9312e40769a.ta
|       |-- 380231ac-fb99-47ad-a689-9e017eb6e78a.ta
|       |-- 484d4143-2d53-4841-3120-4a6f636b6542.ta
|       |-- 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.ta
|       |-- 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.ta
|       |-- 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.ta
|       |-- 5dbac793-f574-4871-8ad3-04331ec17f24.ta
|       |-- 614789f2-39c0-4ebf-b235-92b32ac107ed.ta
|       |-- 690d2100-dbe5-11e6-bf26-cec0c932ce01.ta
|       |-- 731e279e-aafb-4575-a771-38caa6f0cca6.ta
|       |-- 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.ta
|       |-- 8aaaf200-2450-11e4-abe2-0002a5d5c51b.ta
|       |-- a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.ta
|       |-- a734eed9-d6a1-4244-aa50-7c99719e7b7b.ta
|       |-- b3091a65-9751-4784-abf7-0298a7cc35ba.ta
|       |-- b689f2a7-8adf-477a-9f99-32e90c0ad0a2.ta
|       |-- b6c53aba-9669-4668-a7f2-205629d00f86.ta
|       |-- c3f6e2c0-3548-11e1-b86c-0800200c9a66.ta
|       |-- cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.ta
|       |-- d17f73a0-36ef-11e1-984a-0002a5d5c51b.ta
|       |-- e13010e0-2ae1-11e5-896a-0002a5d5c51b.ta
|       |-- e626662e-c0e2-485c-b8c8-09fbce6edf3d.ta
|       |-- e6a33ed4-562b-463a-bb7e-ff5e15a493c8.ta
|       |-- f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.ta
|       |-- f157cda0-550c-11e5-a6fa-0002a5d5c51b.ta
|       |-- f4e750bb-1437-4fbf-8785-8d3580c34994.ta
|       |-- fd02c9da-306c-48c7-a49c-bbd827ae86ee.ta
|       `-- ffd2bded-ab7d-4988-95ee-e4962fff7154.ta
`-- usr
    |-- bin
    |   |-- optee_example_acipher
    |   |-- optee_example_aes
    |   |-- optee_example_hello_world
    |   |-- optee_example_hotp
    |   |-- optee_example_plugins
    |   |-- optee_example_random
    |   `-- optee_example_secure_storage
    |-- include
    |   |-- ck_debug.h
    |   |-- optee_client_config.mk
    |   |-- pkcs11.h
    |   |-- pkcs11_ta.h
    |   |-- tee_bench.h
    |   |-- tee_client_api.h
    |   |-- tee_client_api_extensions.h
    |   |-- tee_plugin_method.h
    |   `-- teec_trace.h
    |-- lib
    |   |-- libckteec.a
    |   |-- libckteec.so -> libckteec.so.0
    |   |-- libckteec.so.0 -> libckteec.so.0.1
    |   |-- libckteec.so.0.1 -> libckteec.so.0.1.0
    |   |-- libckteec.so.0.1.0
    |   |-- libteec.a
    |   |-- libteec.so -> libteec.so.1
    |   |-- libteec.so.1 -> libteec.so.1.0.0
    |   |-- libteec.so.1.0 -> libteec.so.1.0.0
    |   |-- libteec.so.1.0.0
    |   `-- tee-supplicant
    |       `-- plugins
    |           `-- f07bfc66-958c-4a15-99c0-260e4e7375dd.plugin
    `-- sbin
        `-- tee-supplicant

ターゲット上のコンテナに展開するために、tarball で固めます。

[PC ~]$ tar -caf optee.tar.gz -C out .

	「アプリケーションをコンテナで実行する」 を参考にしてコンテナ作成の時に組み込むことをお勧めします

ターゲットデバイスで debian コンテナを起動して、その上で OP-TEE を動作させます。

	xtest の全テストをパスできない場合は環境構築から見直していただくことをお勧めします。問題が解決できないようであればサポートにご連絡ください。

	tee-supplicant は OP-TEE の linux 環境のコンパニオンプロセスです。OP-TEE を利用するためにはなくてはならないものです。自動起動することをお勧めします。詳しくは、「アプリケーションをコンテナで実行する」 を参考にしてください。

NXP Semiconductors が開発するライブラリ plug-and-trust を利用してSE050 にアクセスします。OP-TEE への移植は Foundries.io によって行われ、Github にて公開されています。現状、SE050 の全ての機能を使えるわけではありません。主に暗号強度が弱い鍵長が無効化されています。

現状で対応する処理:

	OP-TEE 向け plug-and-trust の詳細の情報は以下を参照してください。 OP-TEE Enabled Plug and Trust Library 　 https://github.com/foundriesio/plug-and-trust

基本的には CAAM の場合と同様の流れになる。

ディレクトリ構成の概略は以下のとおりです。

├── imx-boot
│   ├── imx-atf
│   ├── imx-mkimage
│   ├── imx-optee-os
│   └── uboot-imx
├── imx-optee-client
├── imx-optee-test
├── optee_examples
├── plug-and-trust
└── out

OP-TEE 向け plug-and-trust をビルドするために必要なパッケージをインストールします。

[PC ~]$ sudo apt install cmake

SE050 を crypto driver として利用するためにコンフィグを修正する。

SE050 向けにビルドするために imx-boot/Makefile を追加する。

$(OPTEE)/out/tee.bin: $(OPTEE)/.git FORCE
        $(MAKE) -C $(OPTEE) O=out ARCH=arm PLATFORM=imx CFG_WERROR=y \
        PLATFORM_FLAVOR=mx8mpevk \
        CFG_NXP_SE05X=y \ 
        CFG_IMX_I2C=y \ 
        CFG_CORE_SE05X_I2C_BUS=2 \
        CFG_CORE_SE05X_BAUDRATE=400000 \
        CFG_CORE_SE05X_OEFID=0xA200 \
        CFG_IMX_CAAM=n \ 
        CFG_NXP_CAAM=n \
        CFG_CRYPTO_WITH_CE=y \ 
        CFG_STACK_THREAD_EXTRA=8192 \ 
        CFG_STACK_TMP_EXTRA=8192 \
        CFG_NUM_THREADS=1 \ 
        CFG_WITH_SOFTWARE_PRNG=n \ 
        CFG_NXP_SE05X_PLUG_AND_TRUST_LIB=~/plug-and-trust/optee_lib/build/libse050.a \ 
        CFG_NXP_SE05X_PLUG_AND_TRUST=~/plug-and-trust/

コンフィグの修正に関する詳細

	SE050 の host 接続用 I2C は最大 3.2 MHz (high speed)ですが、i.MX 8M Plus の i2c の最大周波数は 400kHz のため、遅い通信速度で実装されています CAAM と SE050 の共存は、SE050 を有効にすることによって CAAM の個別のドライバの依存関係が不正になるため、実行時にエラーになる問題があります

Armadillo は消費電力の削減のため SE050 を Deep Power-down モードに設定してパワーゲーティングしている。Deep Power-down モードを解除して SE050 を利用するためには、i.MX 8M Plus に接続されている SE050 の ENA ピンをアサートする必要があります。ENA ピンをアサートすると SE050 は一定時間の後に起動するので SE050 を利用すためには若干の待ち時間が必要となります。OP-TEE OS は起動時にドライバの初期化等を行う実装になっている。そのため、OP-TEE OS が起動する前に生存している SPL (Secondary Program Loader) で Deep Power-down を解除することで待ち時間を稼いでいる。

以下はシステムの起動と SE050 の関係を示したシーケンス図。

図11.3 SE050 向け OP-TEE の起動シーケンス図

ENA をアサートするために以下のように変更する

diff --git a/board/atmark-techno/armadillo_x2/spl.c b/board/atmark-techno/armadillo_x2/spl.c
index a26bc85633..88f5b8560c 100644
--- a/board/atmark-techno/armadillo_x2/spl.c
+++ b/board/atmark-techno/armadillo_x2/spl.c
@@ -111,6 +111,11 @@ static struct fsl_esdhc_cfg usdhc_cfg[2] = {
        {USDHC3_BASE_ADDR, 0, 8},
 };

+#define SE_RST_N IMX_GPIO_NR(1, 12)
+static iomux_v3_cfg_t const se_rst_n_pads[] = {
+       MX8MP_PAD_GPIO1_IO12__GPIO1_IO12 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
 int board_mmc_init(bd_t *bis)
 {
        int i, ret;
@@ -228,6 +233,12 @@ void spl_board_init(void)
        clock_enable(CCGR_GIC, 1);
 #endif

+       imx_iomux_v3_setup_multiple_pads(se_rst_n_pads,
+                                        ARRAY_SIZE(se_rst_n_pads));
+
+       gpio_request(SE_RST_N, "se_rst_n");
+       gpio_direction_output(SE_RST_N, 1);
+
        puts("Normal Boot\n");
 }

imx-optee-os の imx-i2c ドライバには i.MX 8M Plus の対応が入っていないため、レジスタ等の定義を追加する必要がある。imx-optee-os には lf-5.10.y_2.0.0 からSE050 ドライバが取り込まれている。

以下のように修正する。

diff --git a/core/arch/arm/plat-imx/conf.mk b/core/arch/arm/plat-imx/conf.mk
index b4fbfed5..3f6388f3 100644
--- a/core/arch/arm/plat-imx/conf.mk
+++ b/core/arch/arm/plat-imx/conf.mk
@@ -555,7 +555,7 @@ endif

 else

-$(call force,CFG_CRYPTO_DRIVER,n)
-$(call force,CFG_WITH_SOFTWARE_PRNG,y)
+#$(call force,CFG_CRYPTO_DRIVER,n) 
+#$(call force,CFG_WITH_SOFTWARE_PRNG,y) 

 ifneq (,$(filter y, $(CFG_MX6) $(CFG_MX7) $(CFG_MX7ULP)))
diff --git a/core/arch/arm/plat-imx/registers/imx8m.h b/core/arch/arm/plat-imx/registers/imx8m.h
index 9b6a50ee..59fcea88 100644
--- a/core/arch/arm/plat-imx/registers/imx8m.h
+++ b/core/arch/arm/plat-imx/registers/imx8m.h
@@ -42,6 +42,17 @@
 #define IOMUXC_I2C1_SDA_CFG_OFF        0x480
 #define IOMUXC_I2C1_SCL_MUX_OFF        0x214
 #define IOMUXC_I2C1_SDA_MUX_OFF        0x218
+#elif defined(CFG_MX8MP)
+#define I2C1_BASE              0x30a20000
+#define I2C2_BASE              0x30a30000
+#define I2C3_BASE              0x30a40000
+
+#define IOMUXC_I2C1_SCL_CFG_OFF        0x460
+#define IOMUXC_I2C1_SDA_CFG_OFF        0x464
+#define IOMUXC_I2C1_SCL_MUX_OFF        0x200
+#define IOMUXC_I2C1_SDA_MUX_OFF        0x204
+#define IOMUXC_I2C1_SCL_INP_OFF        0x5A4
+#define IOMUXC_I2C1_SDA_INP_OFF        0x5A8
 #endif

 #endif /* __IMX8M_H__ */
diff --git a/core/drivers/imx_i2c.c b/core/drivers/imx_i2c.c
index a318c32c..a9dab31c 100644
--- a/core/drivers/imx_i2c.c
+++ b/core/drivers/imx_i2c.c
@@ -34,6 +34,16 @@
 /* Clock */
 #define I2C_CLK_CGRBM(__x)     0 /* Not implemented */
 #define I2C_CLK_CGR(__x)       CCM_CCRG_I2C##__x
+#elif defined(CFG_MX8MP)
+/* IOMUX */
+#define I2C_INP_SCL(__x)       (IOMUXC_I2C1_SCL_INP_OFF + ((__x) - 1) * 0x8)
+#define I2C_INP_SDA(__x)       (IOMUXC_I2C1_SDA_INP_OFF + ((__x) - 1) * 0x8)
+#define I2C_INP_VAL(__x)       (((__x) == 1 || (__x) == 2) ? 0x2 : 0x4)
+#define I2C_MUX_VAL(__x)       0x010
+#define I2C_CFG_VAL(__x)       0x1c6
+/* Clock */
+#define I2C_CLK_CGRBM(__x)     0 /* Not implemented */
+#define I2C_CLK_CGR(__x)       CCM_CCRG_I2C##__x
 #elif defined(CFG_MX6ULL)
 /* IOMUX */
 #define I2C_INP_SCL(__x)       (IOMUXC_I2C1_SCL_INP_OFF + ((__x) - 1) * 0x8)
@@ -182,7 +192,7 @@ static void i2c_set_bus_speed(uint8_t bid, int bps)
        vaddr_t addr = i2c_clk.base.va;
        uint32_t val = 0;

-#if defined(CFG_MX8MM)
+#if defined(CFG_MX8MM) || defined(CFG_MX8MP)
        addr += CCM_CCGRx_SET(i2c_clk.i2c[bid]);
        val = CCM_CCGRx_ALWAYS_ON(0);
 #elif defined(CFG_MX6ULL)

以下は imx プラットフォームの makefile の問題です。回避するためにコメントアウトします。

修正した後は、ビルドからターゲットボードへの組み込みまで CAAM 向けの OP-TEE と同様の手順で作業することが可能です。 「ブートローダーを再ビルドする」 の作業から開始して組み込みしてください。

「OP-TEE 向け plug-and-trust ライブラリ」 で説明したように一部のアルゴリズムに制限があります。そのため xtest の全てのテスト項目をパスするわけではありません。以下に失敗するテスト項目を列挙する。

以下は特に問題はないが時間がかかるためにフリーズしているかのように見える。

	xtest を行う際にはデフォルトでテストに失敗しても先に進む設定となっています。ただ、時間のかかるテストは無効にすることも可能です。 [container ~]# xtest -x 1006 -x regression_nxp_0003

OP-TEE のアーキテクチャの概要を説明する。ここでは i.MX 8M Plus に搭載される Cortex-A53 コアのアーキテクチャである aarch64 を前提に話を進める。

以下にのシステム図を示す。

図11.4 OPTEE のシステム図

以下のコンポーネントによってシステムが構成される。概要と主な責務について説明する。

TEE を呼び出すフローについて説明する。

CA が OP-TEE 上の TA とのセッションを確立する流れ

CA が TEE Client API を通して TA 上である処理を実行する流れ

	より詳しい内容については公式ドキュメントをご覧ください。 Normal World invokes OP-TEE OS using SMC 　 https://optee.readthedocs.io/en/latest/architecture/core.html#normal-world-invokes-op-tee-os-using-smc

セキュリティ関連の領域を含めた i.MX 8M Plus の物理メモリマップを次に示します。

図11.5 i.MX 8M Plus の物理メモリマップ

imx-optee-os のメモリマップを次に示します。デバッグ等にお役立てください。

ディレクトリ構成の一部抜粋は以下のとおり。

├── cst_3.3.1 
│   ├── crts 
│   ├── keys 
│   └── linux64/bin 
├── imx-boot
├── linux-[VERSION]
├── build-rootfs-[VERSION]
├── csf 
└── out 

PKI 証明書を作るために、証明書のシリアル番号、パスワードを事前に作っておく必要があります。 シリアル番号ファイルとパスワードファイルを作ります。

シリアル番号とパスワードは任意の値を設定してください。

[PC ~]$ cd cst-3.1.1/keys
[PC ~/cst-3.1.1/keys]$ echo "12345678" > serial
[PC ~/cst-3.1.1/keys]$ echo "pass_phrase" > key_pass.txt
[PC ~/cst-3.1.1/keys]$ echo "pass_phrase" >> key_pass.txt

セキュアブート用の PKI tree を作ります。生成する鍵とその証明書は以下のとおりです。

セキュアブートを有効にするためには、i.MX 8M Plus の eFuse に SRK のハッシュ値を書く必要があります。i.MX 8M Plus の OCOTP (On-chip One-Time Programmable Element Controller) のレジスタ経由で書き込むことになります。uboot-imx には OCOTPA へのアクセスを行う fuse コマンドがあります。

ソースコードの取得を行うために 「Armadilloのソフトウェアをビルドする」 の章を参考にしてビルド環境の構築からブートローダーのビルドまでを事前に行ってください。

NXP Semiconductors が提供する cst (code signing tool) はイメージを署名をする機能、CSF をつくる機能を持っているだけで、実際にどの部分を署名するのかは実装依存となっています。Armadillo Base OS では uboot-imx を採用しているので、uboot-imx のガイドに従うことになります。uboot-imx のガイドによると、ビルドログに含まれている情報を抜き出して CSF ファイルを作成するように書かれています。イメージの詳しい情報については 図11.7「ブートローダーの署名済みイメージ」 を参照してください。

取得する情報は以下のとおりです。

CSF 設定ファイルから CSF ファイルを作ります。

csf_spl.bin を作ります。

[PC ~]$ mkdir -p out
[PC ~]$ ./cst-3.3.1/linux64/bin/cst -i csf/csf_spl.txt -o out/csf_spl.bin
Install SRK
Install CSFK
Authenticate CSF
Install key
Authenticate data
CSF Processed successfully and signed data available in out/csf_spl.bin

csf_fit.bin を作ります。

[PC ~]$ ./cst-3.3.1/linux64/bin/cst -i csf/csf_fit.txt -o out/csf_fit.bin
Install SRK
Install CSFK
Authenticate CSF
Install key
Authenticate data
CSF Processed successfully and signed data available in out/csf_fit.bin

以下のファイルができていれば成功です。

[PC ~]$ ls out
csf_fit.bin  csf_spl.bin

CSF をブートローダーイメージ内に予約された領域に書き込みます。seek で書き込み位置を合わせます。ここでのアドレス 0x22e0 と 0x59020 は例です。そのまま実行しないでください。

以下のコマンドを実行する。

[PC ~]$ cp imx-boot/imx-boot_armadillo_x2 out/signed_imx-boot_armadillo_x2
[PC ~]$ dd if=out/csf_spl.bin of=out/signed_imx-boot_armadillo_x2 seek=$((0x22e00)) \
        oflag=seek_bytes bs=4K conv=notrunc 
[PC ~]$ dd if=out/csf_fit.bin of=out/signed_imx-boot_armadillo_x2 seek=$((0x59020)) \
        oflag=seek_bytes bs=4K conv=notrunc 

署名確認対象となる Linux カーネルイメージが実際にメモリに展開されるサイズを取得します。ビルドされた Linux カーネルイメージ (Image) は bss 領域などの領域が省略されます。そのため、ファイルサイズではなく、イメージの内部に組み込まれている値を取得します。

イメージ情報を抽出するために Linux カーネルイメージが必要です。ブートローダーのようにセキュアブート処理を有効にするために再ビルドが必要なわけではないので、ビルド済みイメージを用意するか、「Armadilloのソフトウェアをビルドする」 を参考に Linux カーネルをビルドするかしてください。

コピーしてから編集します。

[PC ~]$ cp imx-boot/uboot-imx/doc/imx/habv4/script_examples/genIVT.pl out/
[PC ~]$ cd out
[PC ~/out]$ vi genIVT.pl

イメージの編集箇所は以下のとおりです。Self Pointer と CSF Pointer を抽出した実際のサイズを基に変更します。イメージの構成についての詳細は 図11.8「Linux カーネルの署名済みイメージ」 を参考にしてください。それ以外の行はそのまま利用してください。

#! /usr/bin/perl -w
use strict;
open(my $out, '>:raw', 'ivt.bin') or die "Unable to open: $!";
print $out pack("V", 0x412000D1); # Signature
print $out pack("V", 0x40480000); # Load Address (*load_address)
print $out pack("V", 0x0); # Reserved
print $out pack("V", 0x0); # DCD pointer
print $out pack("V", 0x0); # Boot Data
print $out pack("V", 0x42300000); # Self Pointer (*ivt) 
print $out pack("V", 0x42300020); # CSF Pointer (*csf) 
print $out pack("V", 0x0); # Reserved
close($out);

CSF 設定ファイルから CSF ファイルを作ります。

csf_linux.bin を作ります。

[PC ~]$ ./cst-3.3.1/linux64/bin/cst -i csf/csf_linux.txt -o out/csf_linux.bin
Install SRK
Install CSFK
Authenticate CSF
Install key
Authenticate data
CSF Processed successfully and signed data available in out/csf_linux.bin

Linux カーネルイメージに CSF を追加することで署名が付加されることになります。

以下のコマンドを実行します。

[PC ~]$ cat out/Image_pad_ivt.bin out/csf_linux.bin > out/signed_Image

PC 上で SD ブート用 microSD カードを作り、Armadillo に挿入して署名済みイメージを書いていきます。ここでは 「Alpine Linux ルートファイルシステムをビルドする」 で説明されているソースツリー alpine/build-rootfs にあるスクリプト build_image を利用します。

Linux カーネルが立ち上がることを確認してください。 Linux カーネルまで立ち上がらない場合、uboot-imx のコマンドで HAB の状態を確認することができます。

Linux 起動まで正常な起動ログ

: (省略)
Booting from mmc ...

## Checking Image at 40480000 ...
Unknown image format!
53522 bytes read in 22 ms (2.3 MiB/s)

Authenticate image from DDR location 0x40480000...

Secure boot enabled 

HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found! 

## Flattened Device Tree blob at 45000000
   Booting using the fdt blob at 0x45000000
   Using Device Tree in place at 0000000045000000, end 0000000045010111

Starting kernel ...
: (省略)

ブートローダーに問題がある場合の起動ログ

: (省略)
spl: ERROR:  image authentication unsuccessful
### ERROR ### Please RESET the board ###
: (省略)

Linux カーネルイメージに問題がある場合の起動ログ

: (省略)
Authenticate image from DDR location 0x40480000...
bad magic magic=0x14 length=0xa1 version=0x0
bad length magic=0x14 length=0xa1 version=0x0
bad version magic=0x14 length=0xa1 version=0x0
Error: Invalid IVT structure

Allowed IVT structure:
IVT HDR      = 0x4X2000D1
IVT ENTRY    = 0xXXXXXXXX
IVT RSV1      = 0x0
IVT DCD      = 0x0
IVT BOOT_DATA = 0xXXXXXXXX
IVT SELF      = 0xXXXXXXXX
IVT CSF      = 0xXXXXXXXX
IVT RSV2      = 0x0
Authenticate Image Fail, Please check 
: (省略)

u-boot コマンドの hab_status

問題がない場合

u-boot=> hab_status

Secure boot enabled

HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found!

Linux カーネルイメージの署名確認で問題がある場合

u-boot=> hab_status

Secure boot disabled

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------
event data:
        0xdb 0x00 0x14 0x45 0x33 0x0c 0xa0 0x00
        0x00 0x00 0x00 0x00 0x40 0x1f 0xdd 0xc0
        0x00 0x00 0x00 0x20

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)

ここでは SRK1 から SRK2 に変更する例を説明します。

ここでは SRK1 から SRK2 に変更する例を説明します。

以下にブートローダーの署名済みイメージと展開先についての例を示します。緑色の部分が BootROM によって署名検証される部分、橙色の部分は SPL によって署名検証される部分になります。

図11.7 ブートローダーの署名済みイメージ

Linux の署名済みイメージと展開先の例は以下のとおりです。水色の部分は u-boot によって署名検証される部分になります。

図11.8 Linux カーネルの署名済みイメージ

以下に SPL (Secondary Program Loader) のブートフローの概要を示します。点線で囲っている部分はセキュアブートで有効になる処理です。

図11.9 SPL セキュアブートのフロー

u-boot のブートフローの概要は以下のとおりです。SPL と同様に点線で囲っている部分はセキュアブートで有効になる処理です。

図11.10 u-boot セキュアブートのフロー