NVME encrypted volume - Orix NX + JP6.2.1 + Secureboot / UEFI secure boot enabled

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
,
1

Hello,

Trying to find solution to correctly implemeted encryption for the user volume on NVME disk with ROOTFS_AB=1 ROOTFS_ENC=1. After flash, device is correctly booted (and I create /opt/nvidia/cryptluks manually), but unable to unlock user volume - “fail to unlock the encrypted dev /dev/nvme0n1p19”. With unfused device and same config everything works well.

commands used for flash:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --showlogs -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” -u ./rsa.pem -v ./sbk.key --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key --no-flash jetson-orin-nano-devkit internal

sudo ROOTFS_AB=1 ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -u ./rsa.pem -v ./sbk.key --no-flash --external-device nvme0n1p1 -p “-T 140000000” -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_ab_enc.xml -S 32GiB --external-only --append --network usb0 jetson-orin-nano-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

Other q about generic passphrase and reenrypt - why UDA has reencrypt = true, but other device have = false? My assumption is that after key changed all devices should be reencrypted.

flash_l4t_t234_nvme_rootfs_ab_enc.xml.txt (12.3 KB)

2

*** Please note that this reply is generated by LLM automatically ***

To address the issue of implementing encryption for the user volume on an NVME disk with ROOTFS_AB=1 and ROOTFS_ENC=1 on a Jetson Orin NX device, we need to examine the provided commands and configuration.

The commands used for flashing the device are:

  1. sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --showlogs -p "-c ./bootloader/generic/cfg/flash_t234_qspi.xml" --uefi-keys uefi_keys/uefi_keys.conf -u rsa.pem -v sbk.key --uefi-enc sym_t234.key --no-flash jetson-orin-nano-devkit internal
  2. sudo ROOTFS_AB=1 ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -u rsa.pem -v sbk.key --no-flash --external-device nvme0n1p1 -p "-T 140000000" -i sym_2t234.key --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_ab_enc.xml --external-only --append --network usb0 jetson-orin-nano-devkit external
  3. 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

The configuration file flash_l4t_t234_nvme_rootfs_ab_enc.xml is used for the external NVME device.

The issue is that the device is unable to unlock the encrypted user volume, with the error message “fail to unlock the encrypted dev /dev/nvme0n1p19”.

To troubleshoot this issue, we need to examine the configuration and the commands used.

  • The ROOTFS_AB=1 and ROOTFS_ENC=1 environment variables are set to enable rootfs A/B redundancy and encryption, respectively.
  • The --external-device nvme0n1p1 option specifies the external NVME device as the target for the rootfs.
  • The --uefi-keys uefi_keys/uefi_keys.conf option specifies the UEFI key configuration file.
  • The --uefi-enc sym_t234.key option specifies the UEFI encryption key.
  • The --no-flash option is used to generate the images without flashing the device.
  • The --external-only option is used to generate the images for the external device only.
  • The --append option is used to append the generated images to the existing images on the device.

Comparing the provided commands with the standard commands for flashing the Jetson Orin NX device with NVME as the rootfs storage, we can see that the commands are similar, but there are some differences:

  • The --mass-storage-only option is not used in the provided commands.
  • The --external-device nvme0n1p1 option is used to specify the external NVME device, but the --external-device option is not used in the standard commands.
  • The --uefi-enc sym_t234.key option is used to specify the UEFI encryption key, but the --uefi-enc option is not used in the standard commands.

To resolve the issue, we can try the following:

  • Use the --mass-storage-only option to generate the images for the mass storage device only.
  • Use the --external-device option to specify the external NVME device, and make sure that the device is properly connected and configured.
  • Verify that the UEFI key configuration file and the UEFI encryption key are correct and properly configured.
  • Try to unlock the encrypted user volume manually using the cryptsetup command, and verify that the encryption key is correct.

Regarding the question about the generic passphrase and re-encryption, the reencrypt option is used to specify whether the device should be re-encrypted after the key is changed. The UDA device has reencrypt=true, which means that the device will be re-encrypted after the key is changed. The other devices have reencrypt=false, which means that they will not be re-encrypted after the key is changed.

The flash_l4t_t234_nvme_rootfs_ab_enc.xml file contains the configuration for the external NVME device, and it specifies the reencrypt option for each device. The UDA device has reencrypt=true, which means that it will be re-encrypted after the key is changed.

In summary, to resolve the issue of implementing encryption for the user volume on an NVME disk with ROOTFS_AB=1 and ROOTFS_ENC=1 on a Jetson Orin NX device, we need to verify the configuration and the commands used, and make sure that the UEFI key configuration file and the UEFI encryption key are correct and properly configured. We can also try to unlock the encrypted user volume manually using the cryptsetup command, and verify that the encryption key is correct.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

5

Verified with 6.2 - same issue. Unable to unlock p19

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 16M 1 loop
zram0 252:0 0 1.9G 0 disk [SWAP]
zram1 252:1 0 1.9G 0 disk [SWAP]
zram2 252:2 0 1.9G 0 disk [SWAP]
zram3 252:3 0 1.9G 0 disk [SWAP]
nvme0n1 259:0 0 931.5G 0 disk
├─nvme0n1p1 259:1 0 400M 0 part /boot
├─nvme0n1p2 259:2 0 400M 0 part
├─nvme0n1p3 259:3 0 31.6G 0 part
│ └─crypt_root 253:0 0 31.6G 0 crypt /
├─nvme0n1p4 259:4 0 31.6G 0 part
│ └─crypt_root_other 253:1 0 31.6G 0 crypt /mnt/crypt_root_other
├─nvme0n1p5 259:5 0 128M 0 part
├─nvme0n1p6 259:6 0 768K 0 part
├─nvme0n1p7 259:7 0 31.6M 0 part
├─nvme0n1p8 259:8 0 128M 0 part
├─nvme0n1p9 259:9 0 768K 0 part
├─nvme0n1p10 259:10 0 31.6M 0 part
├─nvme0n1p11 259:11 0 80M 0 part
├─nvme0n1p12 259:12 0 512K 0 part
├─nvme0n1p13 259:13 0 64M 0 part /boot/efi
├─nvme0n1p14 259:14 0 80M 0 part
├─nvme0n1p15 259:15 0 512K 0 part
├─nvme0n1p16 259:16 0 64M 0 part
├─nvme0n1p17 259:17 0 400M 0 part
│ └─crypt_UDA 253:2 0 384M 0 crypt /mnt/crypt_UDA
├─nvme0n1p18 259:18 0 479.5M 0 part
└─nvme0n1p19 259:19 0 866.1G 0 part

If remove parition and /opt/nvidia/cryptluks and recreate it with sudo gen_luks.sh --erase YES --fs-format ext4 --reboot YES /dev/nvme0n1p19 crypt_user_data everything works fine.

6

hello s.kuchma,

let me double check..
it’s disk encryption (i.e. ROOTFS_ENC=1) to create a new, encrypted APP_ENC partition contains the rest of the file system.
you’re able to enable disk encryption and it worked as expected.

furthermore, you’re going to Enabling Disk Encryption for Dynamically Created Partitions, but, you cannot encrypt a specific partition, right?

7

Hello Jerry,

I’m trying to build image for massflash with AB and ROOTFS_ENC=1 and having space at the end as separate partition that should be encrypted. Have 2 q:

  1. It seems doesnt matter if I define partiton without encrypted=true flag - partiton allways be encrypted. Is it expected behaviour?
sequential basic 419430400 0 0x808 0 16384 **Optional.** This partition may be mounted and used to store user data.

blkid
/dev/mapper/crypt_root_other: UUID=“3f16b1a9-4a14-4bd0-9471-5e64694fcf5c” BLOCK_SIZE=“4096” TYPE=“ext4”
/dev/nvme0n1p9: PARTLABEL=“B_kernel-dtb” PARTUUID=“211987da-7825-4d9a-8f44-602c3b88bd26”
/dev/nvme0n1p11: PARTLABEL=“recovery” PARTUUID=“5b7299bc-f965-4155-9f75-f2251f094a2d”
/dev/nvme0n1p7: PARTLABEL=“A_reserved_on_user” PARTUUID=“0e096a5a-e123-4718-9c59-8726d3c79039”
/dev/nvme0n1p5: PARTLABEL=“A_kernel” PARTUUID=“3f6263b2-93df-42c7-83c5-ef3659bf2c1d”
/dev/nvme0n1p18: PARTLABEL=“reserved” PARTUUID=“1af0ef1b-e158-453f-bdaa-0a69d7886376”
/dev/nvme0n1p3: UUID=“f08e5b99-e785-418a-a0ef-4f84eef840e5” TYPE=“crypto_LUKS” PARTLABEL=“APP_ENC” PARTUUID=“f08e5b99-e785-418a-a0ef-4f84eef840e5”
/dev/nvme0n1p16: PARTLABEL=“esp_alt” PARTUUID=“0faca842-8b5a-46dd-939d-cc161c30c630”
/dev/nvme0n1p1: UUID=“04625c1c-37cd-44ee-86e1-4dc5e011e1f1” BLOCK_SIZE=“4096” TYPE=“ext4” PARTLABEL=“APP” PARTUUID=“bd9617a6-29ec-4440-ba03-08adcd38ca04”
/dev/nvme0n1p14: PARTLABEL=“recovery_alt” PARTUUID=“7893c888-caf1-4681-b950-d718e2329d06”
/dev/nvme0n1p12: PARTLABEL=“recovery-dtb” PARTUUID=“6a1b2bbe-4ce0-4723-a06d-8f3a708f7d29”
/dev/nvme0n1p8: PARTLABEL=“B_kernel” PARTUUID=“26e99468-fe2d-404d-a590-af56175d4872”
/dev/nvme0n1p10: PARTLABEL=“B_reserved_on_user” PARTUUID=“41e305d2-0d38-47c4-8029-bc5d6ba1af32”
/dev/nvme0n1p6: PARTLABEL=“A_kernel-dtb” PARTUUID=“0a3f5f52-9564-4714-a77c-d75f2610ad34”
/dev/nvme0n1p19: UUID=“225d672a-8203-47da-9735-9f987af140d1” TYPE=“crypto_LUKS” PARTLABEL=“user_data” PARTUUID=“6695dabd-209d-4efd-b691-ad237b06b150”
/dev/nvme0n1p4: UUID=“63d29e5d-7200-4c4c-95b4-259d5be87977” TYPE=“crypto_LUKS” PARTLABEL=“APP_ENC_b” PARTUUID=“63d29e5d-7200-4c4c-95b4-259d5be87977”
/dev/nvme0n1p17: UUID=“3fec1ebb-10cd-4165-9cf6-48442f931d32” TYPE=“crypto_LUKS” PARTLABEL=“UDA” PARTUUID=“74780380-e1e3-432c-98b8-835752095b36”
/dev/nvme0n1p2: UUID=“24bfd4e8-50a0-430f-b6a0-e585647ff8ae” BLOCK_SIZE=“4096” TYPE=“ext4” PARTLABEL=“APP_b” PARTUUID=“3cd9b09e-2f9f-4dd6-b6bf-3d4fa47410e8”
/dev/nvme0n1p15: PARTLABEL=“recovery-dtb_alt” PARTUUID=“7d9aac14-aa15-4f5e-b5fa-2d407c408424”
/dev/nvme0n1p13: UUID=“5469-A4DC” BLOCK_SIZE=“512” TYPE=“vfat” PARTLABEL=“esp” PARTUUID=“59eae0c0-3323-417f-894e-aa4612402a64”
/dev/zram3: UUID=“3ed4bf92-f78c-44fd-aa77-c300c118ecde” TYPE=“swap”
/dev/zram1: UUID=“9625a50e-0b03-4476-8bb5-b175a4314c4e” TYPE=“swap”
/dev/mapper/crypt_UDA: UUID=“1ad1e9fc-5a8d-48d5-8304-d3d008c8069c” BLOCK_SIZE=“4096” TYPE=“ext4”
/dev/loop0: SEC_TYPE=“msdos” LABEL_FATBOOT=“L4T-README” LABEL=“L4T-README” UUID=“1234-ABCD” BLOCK_SIZE=“512” TYPE=“vfat”
/dev/mapper/crypt_root: UUID=“1e78ee70-d392-41a3-be88-aaeaeadab8df” BLOCK_SIZE=“4096” TYPE=“ext4”
/dev/zram2: UUID=“cc903be5-96ad-480c-9548-480a6501e86d” TYPE=“swap”
/dev/zram0: UUID=“c801dfa1-1ebb-4533-8b60-4391cac96d92” TYPE=“swap”

  1. In partiton file
sequential basic APP_ENC_SIZE 0 0x8 16384 0 APP_ENC_UUID system_root_encrypted.img_ext **Required.** Contains the encrypted root partition("/"). sequential basic APP_ENC_SIZE 0 0x8 16384 0 APP_ENC_UUID_b system_root_encrypted.img_ext_b **Required.** Contains the encrypted root partition("/"). 
APP_ENC and APP_ENC_b have encrypted="true" reencrypt="false". With massflash should I change to reencrypt="true" to change encryption key from generic to device specific?

Thank you.

BR,

Stanislav