Optee on jetpack 6.0

Hello,

I recently compiled new optee image for Jetpack 6 from sources and everything compiles fine and resulted image gets executed ok.

However, if UEFI payload encryption is being used end result is:

<FF><E4>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
<FF><E1>Unhandled command 0 
<FF><E4>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
<FF><E1>OpteeCallWithArg: Function 0xFFFF0002 not implemented.
GetImageEncryptionInfo: Failed to open session to cpubl payload decryption
 TA 4294901772
L4TLauncher: Unable to get image status: Unsupported
L4TLauncher: Attempting Recovery Boot
Android image header not seen

This is the same issue that I saw earlier with Jetpack 5.1 series: Op-Tee related question

So is this issue present in Jetpack 6.0 series now ? I thought security is on par with Jetpack 5.1 (according to release notes) ?

Best Regards,
Janne

hello jsabzk6o,

BTW, did you using any customize keys?

Hi JerryChang,

Yes there are customized keys, but EKB gets decrypted normally so FV and OEM1 key should be correctly set. UEFI Encryption keys are set as well - this works okay with 5.1.3 but when upgrading to 6.0 this issue came back.

Best regards,
Janne

hello jsabzk6o,

just double check you’ve visit jetson-linux-r363 to download the [Driver Package (BSP) Sources] package.
you should running gen_ekb.py to create EKS image with your keys, and update A_eks partition accordingly.

Hi JerryChange,

My generated EKS image works with factory built TOS image, so I guess EKS image is fine. However, we needsto compile our own image and this compiled image does not work - issue looks awfully same what was in JP 5.1.2.

gen_ekb.py on 6.0 had change where FV was hard coded to script instead passing it as parameter (like in JP 5.1.3).

I’ll double check things on build.

Best Regards,
Janne Savolainen

Hi JerryChang,

Looks like there is issue with build script which defines Early TA’s to be compiled in to OPTEE binary.

if [ "${TARGET_PLATFORM}" == "t234" ]; then
       ccc_prebuilt="${source_dir}/prebuilt/t234/libcommon_crypto.a";
       early_tas="${build_dir}/early_ta/cpubl-payload-dec/0e35e2c9-b329-4ad9-a2f5-8ca9bbbd7713.stripped.elf \
                           ${build_dir}/early_ta/luks-srv/b83d14a8-7128-49df-9624-35f14f65ca6c.stripped.elf"'
fi

This defines 2 TA’s to be included in one of them is responsible for decryption of UEFI playloads.

Now later on in build script there of following lines:

        # Re-build OP-TEE with early TA
        local early_tas="${build_dir}/early_ta/luks-srv/b83d14a8-7128-49df-9624-35f14f65ca6c.stripped.elf"

Looks like early_tas get redefined and CPU BL TA is not compiled in.

Checked build script from git repo and source packages from release and both are same.

Changing script so that cpubl-payload-dec stays defined in early_tas variable fixed the issue for me.

Best Regards,
Janne

hello jsabzk6o,

we would like to reproduce the same locally.
could you please share your steps in details for double checking.

Hi JerryChang,

How to reproduce (if I recall right all the steps):

  • Fetch sources from either git repository (tag: jetson_36.3) or use public source drop from Jetpack 6.0
  • Enable UEFI Payload encryption to be used
  • Compile and create OPTEE Image
  • Create EKB with UEFI Encryption key included
  • Sign and Encrypt boot and recovery images and device tree payloads with UEFI Encryption key
  • Flash TOS Image and EKB QSPI
  • Flash encrypted UEFI payloads to NVME or USB (or what ever media that is being used to boot the system)
  • Boot the device

End result is that boot fails due missing early TA and as this is missing, l4tlaucher does not recognize boot image correctly and is unable to start image execution. Eventually in our case system marks both slots (A and B) as invalid, and tries to reboot to recovery, but as recovery image is encrypted as well it fails as well. Eventually UEFI drops to shell.

Best Regards,
Janne

1 Like

hello jsabzk6o,

thanks for sharing the steps.
there’re fixes check-in to address this issue as well, please expect next JP-6 (i.e. Jetpack-6.1 public release version) will include the fixes.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.