I compiled optee functionality from NVIDIA provided sources and compilation fine, also managed to create working TOS image and verified that it works with xtest fine.
However, when enabling UEFI Secure boot on device that has self-compiled TOS image it results this kind of output on logs:
– snip –
ProcessBootParams
��I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
��Unhandled command 0
��E/TC:?? 00 get_rpc_alloc_res:645 RPC allocation failed. Non-secure world result: ret=0xffff0000 ret_origin=0
E/LD: init_elf:486 sys_open_ta_bin(0e35e2c9-b329-4ad9-a2f5-8ca9bbbd7713)
E/TC:?? 00 ldelf_init_with_ldelf:131 ldelf failed with res: 0xffff000c
��OpteeCallWithArg: Function 0xFFFF0002 not implemented.
GetImageEncryptionInfo: Failed to open session to cpubl payload decryption TA 42
94901772
L4TLauncher: Unable to get image status: Unsupported
– snap –
Looks like L4TLaucher tries to call: GetImageEncryptionInfo().
This function tries to open session to optee with UUID 0e35e2c9-b329-4ad9-a2f5-8ca9bbbd7713, however it looks like that it fails due memory allocation (or at least it reports it back in such way).
I tried to find if there is such TA in NVIDIA op-tee sources but could not find any TA’s with that UUID.
If change nvidia SDK provided TOS image back there is no such error.
Even with above error system boots up correctly.
Few questions:
Where is this TA with UUID 0e35e2c9-b329-4ad9-a2f5-8ca9bbbd7713 ?
Should it be even part of source delivery, and if not, is UEFI Secure boot supposed to work without it ?
it’s the default UUID (0e35e2c9-b329-4ad9-a2f5-8ca9bbbd7713) for the Trusted Application,
you may give it a try by updating user-ta-uuid within below for confirmation. $public_sources/r35.4.1/Linux_for_Tegra/source/public/atf_and_optee/optee/optee_os/ta/trusted_keys/user_ta.mk
Unfortunately changing UUID did not solve the issue.
I looked briefly into UEFI implementation and it looks like UEFI as OP-TEE user expects OP-TEE to contain early ta which does the image decryption.
I tried to check from OP-TEE sources whether there would be such TA available. Release notes for 5.1.2 are mentioning that there is support for “Enhanced secure boot for encrypting kernel, kernel-dtb, and initrd.”.
Is support for that provided at source level, or is it only available as precompiled TOS image ?
may I also know your step in details to create TOS image.
please share all of them specifically so that we could reproduce the issue on the developer kit.
These produce TOS image that passes optee test binary (xtest), but fails to find TA with UUID 0e35e2c9-b329-4ad9-a2f5-8ca9bbbd7713 that was requested by L4TLauncher.
how you update the TOS image? did you perform image flashing for updating A_secure-os partition?
here’re verification steps we’ve done.
please refer to below… Build environment setup $ export CROSS_COMPILE_AARCH64_PATH=$TOP/Toolchain_gcc_9.3/ $ export CROSS_COMPILE_AARCH64=$TOP/Toolchain_gcc_9.3/bin/aarch64-buildroot-linux-gnu- $ export UEFI_STMM_PATH=$TOP/JetPack-5.1.2_AGX-Orin/Linux_for_Tegra/bootloader/standalonemm_optee_t234.bin
Steps to build trusted OS image based on ATF and OP-TEE $ tar xpvf nvidia-jetson-optee-source.tbz2 $ ./optee_src_build.sh -p t234 $ dtc -I dts -O dtb -o ./optee/tegra234-optee.dtb ./optee/tegra234-optee.dts $ mkdir atf_build $ tar -I lbzip2 -C atf_build -xpf atf_src.tbz2 $ cd atf_build/arm-trusted-firmware $ make BUILD_BASE=./build CROSS_COMPILE="${CROSS_COMPILE_AARCH64}" DEBUG=0 LOG_LEVEL=20 PLAT=tegra SPD=opteed TARGET_SOC=t234 V=0 $ cd ../../ $ ./gen_tos_part_img.py --monitor ./atf_build/arm-trusted-firmware/build/tegra/t234/release/bl31.bin --os ./optee/build/t234/core/tee-raw.bin --dtb ./optee/tegra234-optee.dtb --tostype optee ./tos.img
Copy the generated TOS image to updating the secure-os partition $ cp tos.img $OUT/JetPack/JetPack-5.1.2_AGX-Orin/Linux_for_Tegra/bootloader/tos-optee_t234.img $ sudo ./flash.sh -k A_secure-os jetson-agx-orin-devkit mmcblk0p1
Both A and B TOS images were updated simultaneously by performing full recovery flashing with updated TOS image. I am using NVME for booting, so EFI loader (BOOTAA64.efi) was also updated on NVME.
Flashing is pretty mush similar as in SDK, we are using own carrier board without EEPROM, so cvb eeprom size is set to 0. Only difference is that we read module eeprom for later use and reboot back to recovery, then flash QSPI content. This behaviour is visible in attached flash_log.zip and corresponding output from UART is in uart_log.zip
EMMC is otherwise empty, except one partition containing some data.
I believe that flash_log contains steps in detail level.
After bit of digging it looks like that TOS image is missing some early TA which is is requested by L4TLauncher.
By default only luks-srv is put in as early TA.
L4TLauncher requests command from TA, but TA is not found → thus unsupported return value.
UART logs contain also boot after flashing to where TA is not found.
please download the UEFI sources via UEFI Adaptation chapter.
you should see header file which has CPD_TA_UUID defined,
for instance, UEFI/edk2-nvidia/Silicon/NVIDIA/Application/L4TLauncher/L4TOpteeDecrypt.h
may I know the actual use-case for using self-built TOS images?
is it possible to use the TOS image provided by the nvidia SDK?
FYI,
this is a bug for the cpubl payload decryption TA.
we have fixes check-in to rel-35 code-line, they’ll be available in the next Jetpack release, (i.e. r35.5.1)
is it possible to wait for next Jetpack release version for development?
Can you confirm whether fix is included in 5.1.3 Jetpack release or it is it pushed back to 5.1.4 ? 5.1.3 was supposed to be released in December, so I gather that it is pushed back early 2024 ?