I am working on UEFI payload encryption on the Orin Nano dev kit (uSD card) with L4Tv35.4.1. The flash command I used is
////////////////////////////////////////////
echo “0000000000000000000000000000000000000000000000000000000000000000” > uefi_enc.key
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device mmcblk1p1 -c tools/kernel_flash/flash_l4t_external.xml --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc uefi_enc.key -p “-c ./bootloader/t186ref/cfg/flash_t234_qspi.xml” --showlogs --network usb0 jetson-orin-nano-devkit internal
////////////////////////////////////////////
where
uefi_keys.conf has been verified separately by the previous flash that only enables UEFI payload authentication
uefi_enc.key has all 0s because I just want to utilize the default eks.img that comes with L4Tv35.4.1 at this moment. I figure the default eks.img has already contained one key for kernel encryption which is all 0s (based on example.sh), and one key for disk encryption which has been verified by a previous flash that only enables disk encryption.
PKC and SBK are not enabled yet, and no fuse burnt either.
But after the flash and reboot, it seems L4TLauncher cannnot authenticate initrd as below
//////////////////////////////////////////////////////////
Jetson UEFI firmware (version 4.1-33958178 built on 2023-08-01T19:34:02+00:00)
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
** WARNING: Test Key is used. **
…
ÿä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
ÿáL4TLauncher: Attempting Direct Boot
OpenAndReadFileToBuffer: \boot\initrd failed signature verification: Security Vi
olation
ExtLinuxBoot:sds Failed to Authenticate \boot\initrd (Security Violation)
L4TLauncher: Unable to boot via extlinux: Security Violation
L4TLauncher: Attempting Kernel Boot
Android image header not seen
Failed to boot kernel:0 partition
//////////////////////////////////////////////////////////
just for confirmation, did you refer to developer guide, UEFI Secureboot?
FYI, the user_key is specified in eks.img. user_key is purely software, user can define it; 0 user_key means no encryption.
you may see-also similar topics for reference, for example, Topic 249946, Topic 251379.
Yes, I am following the developer guide, UEFI Payload Encryption, which uses --uefi-enc option to provide the key and enable the encryption. The encryption key I use now is all 0s because the default eks.img that comes with L4Tv35.4.1, may have already contained two keys: one is for kernel encryption, which is all 0s (based on example.sh), and the other for disk encryption. I think if I use the same key for encryption, I dont have to create my own eks.img at this moment.
Did I use the wrong key or does UEFI payload encryption requires SBK enabled first (from the post you gave, it seems --uefi-enc is intended to replace --user-key and the comment for --user-key says SBK is required)?
FYI,
although UEFI secure boot can be independently enabled from a low-level bootloader secure boot,
we strongly recommended users enable bootloader secure boot so that the root-of-trust can start from the BootROM.
could you please give it a try to regenerate EKS image.
please also check the commands to generate eks.img
here’s example for Xavier series, please update the chip info accordingly.
for instance, $ python3 gen_ekb.py -chip t194 -kek2_key <kek2_fuse_key_file> -fv <fv_for_ekb_ek> -in_sym_key <sym_key_file> -in sym_key2 <sym2_key_file> -out <eks_image_file>
please check… whether the KEK2 key is burned into the target.
a) If yes…, could you please check whether the burned KEK2 key is the same as the key2.key used in generating eks image?
b) If no…, could you please check whether the key2.key includes zeros key.
you may running partition flash commands to update this individually.
for example, $ sudo ./flash.sh -r -k eks jetson-xavier-nx-devkit mmcblk0p1
you’ll need to update the keys within fv_for_ekb to match the 'fv’ vector used for EKB binary, please see-also Topic 263994 for reference.
FYI, PKC for sign, if PKC is burned, then the KEYFILE users provide is for signing the images. SBK for encryption, if SBK is burned, then the SBKFILE users provide is for encrypting the images.
it’ll still generate binary with sign/encrypt even with all zeros, for example, tos-optee_t234_sigheader.img.encrypt
Thanks JerryChang. As you expect, the root cause is I used a 0 key as the encryption key. With a non-0 key as well as the corresponding eks.img, the UEFI payload encryption works.