Can you please clarify if the issue referred to in Enabling disk encryption and secureboot on internal device 36.3 - #18 by KevinFFF has been resolved in 36.4
hello vpoldra,
please refer to UEFI Payload Encryption section. here’s a specific UEFI payload encryption key, which is user-defined and stored in the encrypted key blob.
hence, you must given the --uefi-keys options for UEFI secureboot signing keys, and also --uefi-enc option for the user-key.
I seemingly flashed the device without errors (on an external NVME, with UEFI secure boot), but the device is not visible via lsusb after reboot (in non-recovery mode), this is what I see from UART debug via minicom:
��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 stmm_handle_variable_authentication:894 Failed to get signed CMAC ffff0007ASSERT [FvbNorFlashStandaloneMm] /out/nvidia/optee_ftpm.t234-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Driv)
Flash log attached:
flash_3-1_0_20241023-182647.log (109.3 KB)
These are the commands for writing the fuses, building the images and flashing that I used (I omitted key and fuse file generation and editing the sectors value in bootloader/generic/cfg/flash_t234_qspi.xml) :
python3 ./source/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py -chip t234 -oem_k1_key kek_optee.key -in_sym_key sym_t234.key -in_sym_key2 sym2_t234.key -in_auth_key uefi_auth.key -out bootloader/eks_t234.img
sudo ./odmfuse.sh -i 0x23 -k rsa.pem -S sbk.key -X fuse.xml jetson-agx-orin-devkit
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 -u ./rsa.pem -v ./sbk.key --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key --no-flash --showlogs -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” jetson-agx-orin-devkit internal
sudo cp bootloader/eks_t234_sigheader_encrypt.img.signed ./tools/kernel_flash/images/internal/
sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -u ./rsa.pem -v ./sbk.key --no-flash --external-device nvme0n1p1 -i ./sym2_t234.key --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml -S 900GiB --external-only --append --network usb0 jetson-agx-orin-devkit external
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -u rsa.pem -v sbk.key --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key --network usb0 --flash-only
Can you help me understand what’s wrong?
hello vpoldra,
(1) did you using [Driver Package (BSP) Sources] from jetson-linux-r3640?
please refer to example.sh for the sample to create EKS image.
(2) let’s exclude UEFI secureboot for verification, for instance, are you able to boot-up by flashing your target with PKC+SBK+Disk encryption?
(3) BTW, you may running with flash script directly since you’re using AGX Orin.
here’s sample flash command-line (PKC+SBK+Disk encryption) for your reference.
$ sudo ROOTFS_ENC=1 ./flash.sh -u PKC -v SBK -i disk_enc.key jetson-agx-orin-devkit mmcblk0p1
-
Yes. Was there anything improper in the creation command I posted?
-
Can I flash w/o secure boot once I’ve written these fuse values with odmfuse.sh (which I have):
<fuse name=\"BootSecurityInfo\" size=\"4\" value=\"0x209\"/>
<fuse name=\"SecurityMode\" size=\"4\" value=\"0x1\"/>
- Isn’t l4t_initrd_flash.sh required for flashing to external NVME?
There seems to be a contradiction between the generation script provided and the documentation at Secure Boot — NVIDIA Jetson Linux Developer Guide 1 documentation :
The UEFI variable authentication key is a 128-bit key stored in a file in the big-endian hexadecimal format.
Here is an example of an auth key file:
0x00000000000000000000000000000000
and the script at source/optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh :
# openssl rand -rand /dev/urandom -hex 16 > auth_t234.key # uefi variables authentication key
# echo "00000000000000000000000000000000" > auth_t234.key
i.e. no “0x” is prepended by the script. As the other keys follow this pattern I assume the documentation is incorrect.
Edit: I noticed Secure Boot — NVIDIA Jetson Linux Developer Guide 1 documentation
stating:
The leading 0x or 0X of a hexadecimal number can be omitted. The Jetson Secure Boot software converts the big-endian hexadecimal format to the format that the Jetson device expects.
Perhaps the same holds true for the uefi variable authentication key, but it’s slightly confusing.
Something else I think is confusing for a lot of people is that – while I believe using disk encryption does not necessarily require using secure boot – the disk encryption page links to OP-TEE for EKB generation which in turn links to Secure Boot for the fuse configurations, and then it’s needed to filter out the minimum required configuration for disk encryption without enabling secure boot.
1 Like
My issue turned out to be the uefi variable authentication key (provided to gen_ekb.py as -in_auth_key) being in the wrong format. Once I build the ekb image with the correct key (generated based on example.sh), everything works,
In case someone might find it useful, I detailed my process here.
hello vpoldra,
got it, thanks for status update.
note, this is mandatory once you’ve updating sym2_t234.key (i.e. disk encryption key)
it looks like the same as mentioned by developer guide,
however, such step-by-step instruction also given a good reference, thanks for sharing!
Yes, I did my best to follow the documentation of course.
PS I would suggest improving the validation for the gen_ekb.py script, so issues with key format can be discovered at an earlier stage.
hello vpoldra,
FYI,
there are 4 magic bytes at the beginning of the EKS image, they are: "EEKB".
so, if these 4 bytes are wrong, you will see “eks image not correct” failure message.
for instance,
$ hexdump -C -n 4 -s 0x24 eks_t234.img
00000024 45 45 4b 42 |EEKB|
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.