こんにちは、
現在、S32G3上でARM TrustZoneを有効化する作業に取り組んでいます。
私の状況は以下の通りです。
私のテストカードでは、Rich OSとOP-TEEを起動できます。NXPリポジトリからこのOP-TEEを取得しました
https://github.com/nxp-auto-linux/optee_os/tree/release/bsp46.0-4.0 。
ビルドプロセス中に、OP-TEEクライアントとOP-TEEサンプルをビルドします。サンプルとして提示された信頼できるアプリに関連するバイナリファイルは、私のテスト用カードのファイルシステム上の適切な場所に存在しています。
サンプルとして提供されている信頼済みアプリをテストしようとしています。そのためには、まずtee-supplicantを起動し、次にテストしたいtrusted-appに関連するバイナリを実行します。
しかし、次のようなエラーが発生します。
E/LD: init_elf:486 sys_open_ta_bin(8aaaf200-2450-11e4-abe2-0002a5d5c51b)
等：？0 ldelf_init_with_ldelf:152 ldelf が res: 0xffff0000 で失敗しました
optee_example_hello_world: TEEC_Opensession がコード 0xffff0000 で失敗しました。発生元 0x3
コードを確認したり、他のフォーラムを読んだりしたところ、tee-supplicantはOP-TEEからの指示を受け取っていないようです。
より正確に言うと、/proc/$(tee_supplicant_pid)/maps を見ると、OP-TEE の共有マップが tee_supplicant のアドレス空間にマッピングされていないことがわかります。
[ 0.000000] OF: 予約済みメモリ: 0x00000000fe000000..0x00000000ff3fffff (20480 KiB) nomap 再利用不可 optee@fe000000
[ 0.000000] OF: 予約済みメモリ: 0x00000000ff400000..0x00000000ff5fffff (2048 KiB) nomap 再利用不可optee-shm@ff400000
しかし、/proc/$(tee_supplicant_pid)/maps では：
5567a84000-5567a8f000 r-xp 00000000 01:00 402 /usr/sbin/tee-supplicant
5567a8f000-5567a90000 r--p 0000a000 01:00 402 /usr/sbin/tee-supplicant
5567a90000-5567ad1000 rw-p 0000b000 01:00 402 /usr/sbin/tee-supplicant
5567ad1000-5567ad2000 rw-p 00000000 00:00 0
55a4ca6000-55a4cc7000 rw-p 00000000 00:00 0 [ヒープ]
7fbe028000-7fbe02a000 rw-p 00000000 00:00 0
7fbe02a000-7fbe1ad000 r-xp 00000000 01:00 155 /lib/libc.so.6
7fbe1ad000-7fbe1b0000 r--p 00183000 01:00 155 /lib/libc.so.6
7fbe1b0000-7fbe1b2000 rw-p 00186000 01:00 155 /lib/libc.so.6
7fbe1b2000-7fbe1bf000 rw-p 00000000 00:00 0
7fbe1bf000-7fbe1c2000 r-xp 00000000 01:00 184 /lib/libteec.so.2
7fbe1c2000-7fbe1c3000 r--p 00002000 01:00 184 /lib/libteec.so.2
7fbe1c3000-7fbe1c4000 rw-p 00003000 01:00 184 /lib/libteec.so.2
7fbe1c4000-7fbe1c6000 rw-p 00000000 00:00 0
7fbe1c6000-7fbe1c8000 r--p 00000000 00:00 0 [vvar]
7fbe1c8000-7fbe1c9000 r-xp 00000000 00:00 0 [vdso]
7fbe1c9000-7fbe1f0000 r-xp 00000000 01:00 151 /lib/ld-linux-aarch64.so.1
7fbe1f0000-7fbe1f2000 r--p 00026000 01:00 151 /lib/ld-linux-aarch64.so.1
7fbe1f2000-7fbe1f3000 rw-p 00028000 01:00 151 /lib/ld-linux-aarch64.so.1
7fbe1f3000-7fbe1f4000 rw-p 00000000 00:00 0
7fc6441000-7fc6462000 rw-p 00000000 00:00 0 [スタック]
今のところ、なぜこのようなことが起こるのか原因が分かりません。
どなたか何かご存知の方はいらっしゃいますか？
よろしくお願いいたします。
ユーザー6
こんにちは、 @user6
ご返信ありがとうございます。
どうやらあなたはBSP45のカーネルとBSP46のカーネルが混在した環境で作業しているようですね。BSP46で完全にテストしてみることをお勧めします。
簡単に言うと、Yoctoを使って構築してみると良いでしょう。
BR
チェイン
こんにちは、 @chenyin_h さん。
迅速なご回答ありがとうございます。
私はカスタム基板でテストを行っています。
私のセットアップについて：
- LinuxはBSP 45.0-6.6.87-rtに基づいています
- このdtsは、OP-TEEの要件に適合するカスタムdtsです。
- RootfsはOP-TEEの要件を満たす古典的なものです
この設定で問題になりそうな点はありますか？
よろしくお願いいたします。
ユーザー6
こんにちは、 @user6
投稿ありがとうございます
テスト環境についてもう少し詳しく教えていただけますか？
1. それは、自社開発のボードでテストされたものですか、それともリファレンスボード（例えばRDB3やEVB3）でテストされたものですか？
2. あなたはBSP46で使用されているOPTEEバージョンに取り組んでいると理解していますが、テスト環境もBSP46（Linux、dts、Rootfsなど）に基づいているのでしょうか？
BR
チェイン
こんにちは、 @chenyin_h さん。
お返事ありがとうございます。
BSP46 で完全に試してみましたが、bsp46 のベースとなっている optee-os のバージョンが 4.0.0 であるため、optee-client と optee-examples のバージョンも 4.0.0 に変更しました。
しかし、エラーは依然として発生している。S32G3ベースのSoCにTrustZoneを統合した社内事例はありますか？
よろしくお願いいたします。
ユーザー6