Device with secure-boot enabled doesn't boot after updating to tegra release 35.6.1

[elbbits2]

Hello,

we are running our Yocto on a Jetson Xavier AGX Industrial based target. It's successfully running now for more than a year with using the tag 35.4.1 (kirkstone) of layer meta-tegra. The device is fused, with secure boot enabled for bootloaders and UEFI.

After updating to meta-tegra release 35.6.1 (still kirkstone) the device refuses to boot with this error:

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
E/TC:? 0 jetson_user_key_pta_uefi_vars_auth:920 UEFI variable auth key not set !
E/TC:? 0 stmm_handle_variable_authentication:910 Failed to get signed CMAC ffff0008

ASSERT [FvbNorFlashStandaloneMm] /dvs/git/dirty/git-master_linux/out/nvidia/optee.t194-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/VarIntCheck.c(922): ((BOOLEAN)(0==1))

I read in the forum that this might be related to the UEFI Variable Protection that is now enabled by default and that the issue could be solved with creating my own EKB partition (till now the default eks_t194.img was used).

So I created my own eks_t194.img and installed it with a bbappend to tegra-bootfiles. For creating the EKS image on my own I downloaded the op-tee sources (BSP Driver Sources for Jetson 35.6.1) and used the example.sh:

# This is default KEK2 root key for unfused board
echo "00000000000000000000000000000000" > kek2.key

# This is the fixed vector for deriving EKB root key from fuse.
# It is expected user to replace the FV below with a user specific
# FV, and code the exact same user specific FV into OP-TEE.
echo "bad66eb4484983684b992fe54a648bb8" > fv_ekb_t194

# Generate user-defined symmetric key files
# A random generate key is recommended for production, and a specified key is recommended for testing
# For each key, there are reference examples for generating random key and specifying keys.
openssl rand -rand /dev/urandom -hex 16 > sym_t194.key
openssl rand -rand /dev/urandom -hex 16 > sym2_t194.key
openssl rand -rand /dev/urandom -hex 16 > auth_t194.key

python3 gen_ekb.py -chip t194 -kek2_key kek2.key \
        -fv fv_ekb_t194 \
        -in_sym_key sym_t194.key \
        -in_sym_key2 sym2_t194.key \
        -in_auth_key auth_t194.key \
        -out eks_t194.img

Unfortunately the behaviour persists with still the same error message. I uses kek2 filled with zeros, because we never fused a value for kek0, kek1 and kek2 - only the secure boot key and the public key hash. We were not aware that kek2 might be needed in the future. Did I miss something? Is there anything more that needs to be changed?

[madisongh]

We did mention this breaking change on the wiki page for R35.5.0, when it was introduced.

In generating the EKB, you should only need the "auth" key, since the other two are used for other purposes, but it probably doesn't hurt to include all three. Did you flash the updated EKB to your device when you tested? Or if you used an OTA update system, did you make sure that the update included updating the EKB?

But I'm not sure what the expected behavior is when you've locked down the secure boot fuses, but left the KEKs all zeroes... hopefully it will work just by specifying the key in the EKB. If not, you may need to patch the UEFI code to disable the variable authentication.

[elbbits2]

Yes, I flashed the updated EKB (eks.img), also verified that the hash sum is equal to the image I generated with gen_ekb.py .

I just noticed that the interesting logs start even earlier with:

I/TC: OP-TEE version: 3.22 (gcc version 11.3.0 (GCC)) #1 Thu Nov 20 07:56:42 UTC 2025 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
E/TC:0 0 ekb_extraction_process:321 Tried all EKB_RKs but still can't extract the EKB image.
E/TC:0 0 jetson_user_key_pta_init:1039 jetson_user_key_pta_init: Failed (ffff000f).
E/TC:0 0 call_initcalls:43 Initcall __text_start + 0x000f0d38 failed
I/TC: Primary CPU switching to normal world boot

Would be really nice to know if leaving KEK2 at all zeros and burning the production fuse is a valid option or actually screwed up my devices.

Meanwhile I was able to boot the device with disabling variable authentication. I set CheckVarStoreIntegrity = FALSE in edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/FvbNorFlashStandaloneMm.c. Is that a proper solution or is there a better way to disable variable authentication?

[madisongh]

Would be really nice to know if leaving KEK2 at all zeros and burning the production fuse is a valid option or actually screwed up my devices.

That depends on your definition of "screwed up".... there are certain security-related features you cannot use, but if you didn't need them before, then with your patch you're no worse off.