Orin NX UEFI can't enroll keys

I am attempting to enable UEFI secureboot on a custom Orin NX-based board. After programming my images, instead of booting up L4tLauncher, it’s dropping into the UEFI shell. The device boots off of QSPI, with the subsequent images in NVME. I have no fuses programmed.

Using the debug version of the UEFI firmware, when I attempt to flash the board over USB, an error appears on the console:

Process SysPrep0000 (Enroll Default Keys App) ...
add-symbol-file /home/steve/nvidia-uefi-35.3.1/Build/Jetson/DEBUG_GCC5/AARCH64/SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp/DEBUG/EnrollFromDefaultKeysApp.dll 0x3F75D8000
Loading driver at 0x003F75D7000 EntryPoint=0x003F75DBD98 EnrollFromDefaultKeysApp.efi

EnrollFromDefaultKeysApp: Cannot set CUSTOM_SECURE_BOOT_MODE: Security Violation

During the subsequent boot, I see:

Jetson UEFI firmware (version r35.3.1-d0c8c1ad built on 2024-02-07T18:10:28-05:0
0)
ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.
**********************************
**  WARNING: Test Key is used.  **
**********************************
**  WARNING: Test Key is used.  **
add-symbol-file /home/steve/nvidia-uefi-35.3.1/Build/Jetson/DEBUG_GCC5/AARCH64/SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp/DEBUG/EnrollFromDefaultKeysApp.dll 0x428DD8000
Loading driver at 0x00428DD7000 EntryPoint=0x00428DDBD98 EnrollFromDefaultKeysApp.efi

EnrollFromDefaultKeysApp: Skipped - USER_MODE

It attempts to boot of off NVME:
[Bds]Booting UEFI WD IX SN530 SDBPNPZ-512G-XI 21081L800049 1
But then moves on to a network boot:
[Bds]Booting UEFI HTTPv4 (MAC:48B02DF7AEFD)
Eventually it gives up on this and drops out to the UEFI shell.

My guess is that the inability to enroll the keys is leading to it deciding the images are not properly signed and therefore not booting them. Assuming that’s correct…

What can cause the security violation?

Another posting indicated that there needs to be a non-zero keys in the EKS image. I have done that, following example.sh as described in the Disk Encryption secureboot documentation. However, the information regarding UEFI in example.sh is not clear. While UEFI uses OpenSSL-generated RSA keys (PK, KEK, DB), example.sh indicates that the files uefi_pub.key and uefi_enc.key should be created with simple hex strings.

How do the RSA UEFI keys passed via --uefi-keys and put into UefiDefaultSecurityKeys.dtbo relate to the uefi key files put into eks_t234.img by gen_ekb.py?

I’m building the image using:

sudo BOARDID=$BOARDID BOARDSKU=$BOARDSKU FAB=$BOARDFAB \
        EXTOPTIONS="--uefi-keys uefi_keys/uefi_keys.conf" \
        ./tools/kernel_flash/l4t_initrd_flash.sh \
        --no-flash \
        -c flash_t234_custom_nvme.xml \
        -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml --uefi-keys uefi_keys/uefi_keys.conf" \
        -S 470GiB \
        --external-device nvme0n1p1 \
        --network usb0 \
        --showlogs \
        jetson-orin-nx-custom external

and I’m programming the board with:

sudo BOARDID=$BOARDID BOARDSKU=$BOARDSKU FAB=$BOARDFAB \
        EXTOPTIONS="--uefi-keys $UEFI_KEY_DIR/uefi_keys.conf" \
        ./tools/kernel_flash/l4t_initrd_flash.sh \
        --flash-only \
        -c flash_t234_custom_nvme.xml \
        -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml --uefi-keys uefi_keys/uefi_keys.conf" \
        -S 470GiB \
        --external-device nvme0n1p1 \
        --network usb0 \
        --showlogs \
        jetson-orin-nx-custom external

Thanks,
Steve

Hi steve.schefter,

Are you using the devkit or custom board for Orin NX?
What’s your Jetpack version in use?

Do you want to enable secure boot or disk-encryption?

Why you don’t specify the PKC and SBK in your command?

It is a custom Orin NX-based board

JetPack 5.1.1 with Jetson Linux 35.3.1.

In the end, I will be using:

  • secure boot, as secured with PKC and SBK
  • UEFI secure boot, as secured with the UEFI keys
  • encrypted RFS

This question is just about UEFI secure boot. The other items are working.

It makes no difference if I:

  • use those options on a board which has the PKC and SBK blow into the fuse
  • don’t use those options on a board which doesn’t have the PKC and SBK fuses blow

For my posting here, I’ve attempted to keep it focused on my question which is about UEFI, so I have not included PKC/SBK secure boot or root FS encryption (other than to comment what I saw regarding the creation of the eks image).

Regards,
Steve

Have you referred to UEFI Secureboot for details?

Is your current issue about it could not boot after you enable UEFI secureboot?
If so, please share the detailed steps how you generate the UEFI key.

In addition, do you have any custom partition layout changed for your custom carrier board?

hello steve.schefter,

please double check you’ve generate the PK, KEK, and db RSA keypairs, and updating UEFI payloads correctly.
plese see-also Generate Signed UEFI Payloads.

I have generated them according to the Nvidia notes:
openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days 9125 -subj “/CN=Varmint Platform Key/” -out uefi_keys/PK.crt
openssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj “/CN=Varmint Key Exchange Key/” -out uefi_keys/KEK.crt
openssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj “/CN=Varmint Key
Exchange Key/” -out uefi_keys/KEK.crt
openssl req -newkey rsa:2048 -nodes -keyout db_1.key -new -x509 -sha256 -days 3650 -subj “/CN=Varmint Signature Database key/” -out uefi_keys/db_1.crt
sudo tools/gen_uefi_default_keys_dts.sh uefi_keys/uefi_keys.conf

My uefi_keys.conf has:
UEFI_PK_KEY_FILE=“PK.key”;
UEFI_PK_CERT_FILE=“PK.crt”;
UEFI_KEK_KEY_FILE=“KEK.key”;
UEFI_KEK_CERT_FILE=“KEK.crt”;
UEFI_DB_1_KEY_FILE=“db_1.key”;
UEFI_DB_1_CERT_FILE=“db_1.crt”;

Per my original question, I’m producing the payloads by including the –uefi-keys option to flash.sh. That’s all that should be required to create the payloads, shouldn’t it?

Also note that the reported issue is failing to set the CUSTOM_SECURE_BOOT_MODE. That occurs as I attempt to flash the generated images to the board, not when UEFI authenticates my images during a subsequent reboot.

Looking at the source of the UEFI firmware and EnrollFromDefaultKeysApp specifically, this setting of the secure boot mode is performed by that app just prior to it actually enrolling the keys. So it doesn’t seem to be the keys themselves that are the source of the error. To hopefully further confirm that, the log also shows “Processing “UEFI default Keys” DTB overlay” without any indication of error. (“UEFI default Keys” is the name in UefiDefaultSecurityKeys.dtbo which contains the UEFI keys).

I note that the documentation for generating UEFI signed images calls for invoking flash.sh with the --uefi-keys option. However, the board has both internal (QSPI) and external (NVME) devices. For this reason I have used tools/kernel_flash/l4t_initrd_flash.sh.

tools/kernel_flash/l4t_initrd_flash.sh invokes flash.sh a few times. Once for the flash_t234_qspi.xml device partition configuration file and once for the NVME device partition configuration file. Looking at the logs, I have found that using a combination of:

-p "...l --uefi-keys uefi_keys/uefi_keys.conf"

and

EXTOPTIONS="--uefi-keys uefi_keys/uefi_keys.conf"

causes flash.sh to be called with the --uefi-keys parameter each time.

Alternatively, I can invoke tools/kernel_flash/l4t_initrd_flash.sh twice. First, with the QSPI device partition configuration file. And second with the --append option and the NVME device partition configuration file. I have seen posts by you @JerryChang which do that when creating interal + external images with RFS encryption.

I see the same error that I reported with either of those options.

What is the proper command to generate UEFI-signed images when I have both internal and external devices? The documentation for generating UEFI signed images doesn’t touch that situation, nor does tools/kernel_flash/README_initrd_flash.txt.

hello steve.schefter,

is your target also fused with KEK?
note, db and dbx are UEFI authenticated variables. they are protected by KEK (which is protected by PK, and PK is self-signed).
any corruptions will cause signature verification failure.

please see-also Topic 249946,
there’s an issue/workaround with PKC + SBK + DiskEncryption + UEFI secureBoot if you’re using JP-5.1.1 release version.

Hi JerryChang.

I don’t see the KEK fuse for Orin. Are you thinking of Xavier or am I missing that key? And if you were thinking of Xavier, is there an equivalent for Orin that must be blown for UEFI? The board I’m currently testing with has no fuses blown.

Thanks for the heads up. I’ll take a closer look in the morning. However, I’m not currently using PKC, SBK or disk encryption (see the commands I’m using in my original post).

Steve

hello steve.schefter,

although UEFI secure boot can be independently enabled from a low-level bootloader secure boot, we strongly recommended users enable bootloader secure boot (i.e. PKC, SBK…etc) so that the root-of-trust can start from the BootROM.

anyways, let me arrange resources to setup an environment to reproduce this locally.

Hi JerryChang.

Yes, I do intend to include bootloader secure boot. In fact the first time I ran into this issue was on a board with the PKC and SBK fuses blown and I was signing the images accordingly. I moved to a board without that just to try to simplify the UEFI debugging.

Very much appreciated. Please do consider the case of mixed internal and external images (QSPI and NVME) as I think that’s part of the issue here and something that’s not covered by the documentation. And to complicate it further, since I’m going to eventually include RFS encryption too, I think I’m going to eventually have to generate the QSPI images with one run of flash.sh/ l4t_initrd_flash.sh and then generate (–append?) the NVME images with a second run of flash.sh/ l4t_initrd_flash.sh.

Hi steve.schefter,

We’ve verified the workflow to enable UEFI secureboot on the devkit with R35.5.0 for internal eMMC.

Have you referred to the steps in Linux_for_Tegra/tools/README_uefi_secureboot.txt and verify if you could enable it for eMMC?

Or you could refer to the steps in 3. Enable UEFI Secureboot at run-time from the kernel. to enable it.