I’m relatively new to low-level Jetson customizations, so please consider my expertise in regards to my question and any answers that you may provide. I’m using R36.3.0 and a Jetson AGX Orin DevKit as my development/learning platform with an Ubuntu 22.04 host (yes, I know the documentation says only 18.04 and 20.04 are compatible, but I believe I have loaded all the necessary packages).
I’m attempting to implement secure boot in stages, with first stage being the Jetson bootloader components as its my understanding that I can do that stage without doing the UEFI secure boot. Perhaps that is my misunderstanding? Anyways, using the Secure Boot instructions in the R36.3.0 developer guide, I was able to successfully create: a PKC, a PKC hash, and a SBK. I was able to use those keys to define and burn the device’s fuses as well as sign/encrypt the bootloader images (at least, I didn’t get any errors during that process). After flashing, it “appears” it is working, since I’m getting through the MB1 and MB2 boot stages. But, then I get to the point where UEFI is loaded and get the following errors. Could anyone shed some light on what is happening here and how I can correct it? Also, can you please confirm that since MB1 and MB2 appear to be completing their boot stages, that I have those aspects of secure boot working?
Thanks,
Jim
I> MB2 finished
▒▒NOTICE: BL31: v2.8(release):e12e3fa93
NOTICE: BL31: Built : 09:56:21, May 6 2024
I/TC:
I/TC: Non-secure external DT found
I/TC: OP-TEE version: 3.22 (gcc version 11.3.0 (Buildroot 2022.08)) #2 Mon May 6 17:07:49 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check Porting guidelines — OP-TEE documentation documentation
I/TC: Primary CPU initializing
I/TC: Test OEM keys are being used. This is insecure for shipping products!
I/TC: Primary CPU switching to normal world boot
▒▒
Jetson UEFI firmware (version 36.3.0-gcid-36191598 built on 2024-05-06T16:58:59+00:00)
▒▒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:?? 00 jetson_user_key_pta_uefi_vars_auth:904 UEFI variable auth key not set !
E/TC:?? 00 stmm_handle_variable_authentication:910 Failed to get signed CMAC ffff0008
I followed the exact steps in the NVIDIA R36.3.0 instructions for enabling the secure boot aspects of the bootloader. My fuse file looks like this (with some of the XML tags removed in order to view in this reader):
genericfuse MagicId=“0x45535546” version=“2.0.0”>
fuse name=“PublicKeyHash” size=“64” value=“0x My Key Info Is Here”/>
fuse name=“SecureBootKey” size=“32” value=“0x My Key Info Is Here”/>
fuse name=“BootSecurityInfo” size=“4” value=“0x9”/>
fuse name=“SecurityMode” size=“4” value=“0x1”/>
/genericfuse>
The signing and encrypting seems to work just fine. I’m assuming that since I’m able to get to the UEFI load portion of the boot sequence, this confirms the aspects of the Jetson secure boot are working (MB1/MB2), correct?
From the error message, it appears that UEFI variable authentication is attempting to take place? I was under the impression this was something that was enabled through the UEFI secure boot configuration steps and not on by default. Is that not the case? I have not modified anything with the UEFI. I’m using the default image provided as a part of the R36.3.0 image.
So, I think I “fixed” it, but would like an explanation for why this needed to be done.
I came across another post (JetPack 5.1.3 - Boot error with all security enabled - #7 by resi58) where it was recommended to create another “eks_t234.img”. I generated a new image with all the default keys “0s” and used that image to flash and boot. I was able to do so successfully. I now have a Jetson running with secure boot enabled for its bootloader components and UEFI without secure boot.
So the question is why did I need to do this? Does the default "eks_t234.img’ not have default keys of “0s” already? Wouldn’t I have encountered the same issue before I made the Jetson bootloader secure boot change?
here’s something wrong, since you’ve enable PKC+SBK, you should also burn OemKeyValid fuse variable.
please see-also Jetson Orin Fuse Specification about Bit-9 of FUSE_BOOT_SECURITY_INFO_0 .
for instance,
BootSecurityInfo should be… <fuse name="BootSecurityInfo" size="4" value="0x209"/> if you fused with RSA3K+SBK.
If the R36.3.0 version of “eks_t234.img” already has 0s for the default keys, then why did recreating that image with 0s as the keys correct my issue? I don’t understand that.
Why does the “OemKeyValid” bit need to be set in my configuration per your suggestion? I was under the impression that it only needed to be set if I was overriding the default “OemK1” key in my fuse configuration file, which I’m not. Even in the NVIDIA’s own developer guide, it is not setting that bit in a similar example to what I am using (see first example below), but they are setting it whenever the “OemK1” key is set (see second example below). Or is the NVIDIA documentation lacking…in that if you use a PKC+SBK combination, you must define a “OemK1” key? Could you please explain? Is there some dependency between a PKC+SBK combination and the “OemK1” key that I’m not understanding? The NVIDIA documentation says the “The K1/K2 keys are used for other security applications”. Could you please explain what this means?
Example Orin Fuse Configuration File to Program an RSA-3K Key
maybe part of op-tee binary did not update accordingly, I don’t know. we may dig into this.
at the moment, please recreating that EKS image with all 0s as your solution.
>> Q2
the OemKeyValid bit, for instance, Bit-9 of FUSE_BOOT_SECURITY_INFO_0 it controls whether the boot images need to be encrypted/signed or not.
for example,
if OemKeyValid is not burned. it should booting with non-encrypted and non-signed boot images.
in your use-case, once PKC+SBK are burned, it’s a must to provide signed and encrypted boot images for image flashing, (or, burning additional fuses).