Disk Encryption Feature Support

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
,
1

There are a couple of features that Jetpack provides that are unclear if they are supported while running disk encryption:

  1. Is image based OTA supported while running disk encryption?
  2. Is A/B rootfs supported while running disk encryption?
3

hello user141301,

quick question, may I know which JetPack release you’re currently working on.

4

Currently on 32.7.1

5

hello user141301,

ya, that’s supported.

[EDIT]

please refer to comment #11.
Image-based OTA does not support the case of disk encryption enabled.

6

2 additional questions:

  1. In NVIDIA Jetson Linux Developer Guide : Over-the-Air Update | NVIDIA Docs the section titled “Steps Performed on the Jetson Device” states that the first step is to modify extlinux.confto setup initrd - when running with disk encryption, this file is signed/encrypted and thus is random bytes in an editor and I cannot simply append the parameters as requested in that section. Of course nv_ota_start.sh checks for that line with a grep as a first step so the script will fail if its not there - and even if i generate a new extlinux.conf that is properly signed/encrypted, the script is unable to decrypt the file to properly parse it. What is the correct way to support image based OTA with disk encryption? I have not been able to find any pointers in the documentation.

  2. Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt does not contain a description for modifying the corresponding flash_*.xml files for using disk encryption with A/B Rootfs. I attempted to use the same nomenclature as the non-encrypted a/b rootfs example by duplicating the encrypted root partitions and postfixing the corresponding _a and _b to them, but was unable to get a device to boot this way. Is there a working example XML file that can be provided for this scenario?

7

hello user141301,

please refer to developer guide, Over-the-Air Update with Rootfs Redundancy Enabled.
re-cap as below…

When the option “Unified bootloader A/B and rootfs A/B” is enabled, the Jetpack Debian package over-the-air update is disabled.

Image-based OTA should works.

BTW,
There is a known issue when Rootfs A/B is enabled. When booting up from rootfs-A, rootfs-B does not get automatically unlocked by intird on A. The vice verse is also true. This problem will cause rootfs-B unmountable. Consequently, rootfs image OTA can’t be proceeded.

This issue will be fixed in next release. (i.e. l4t.r32.7.2 or later…)
A workaround is to manually add in the unlock command into initrd. Detail steps can be found in L4T Developer Guide at Disk Encryption chapter for this session, [To modify initrd to unlock additional encrypted file systems].
The UUID identifier needed for A can be found in the /etc/crypttab in initrd in partition APP_b with a line similar to below: crypt_root UUID=b5600ed6-69e7-42b8-bee3-ecfdd12649d1

8

So I’ve started with trying to perform OTA update with only a single encrypted rootfs (I do not yet have A/B rootfs enabled) and I am running into the issue above, that the OTA fails to start due to extlinux.conf being encrypted - and I am unable to modify extlinux.conf since it is encrypted. Im not sure I follow how the above gets around the extlinux.conf encryption issue.

9

hello user141301,

could you please share your steps to generate the OTA update payload package.
had you also update EKB partition with your EKB key used for disk encryption?

10
  • As a first pass, I am simply trying to run an update with the same version as i have currently installed. To generate the OTA image I do the following:
  1. Download OTA tools from: https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/t186/ota_tools_r32.7.2_aarch64.tbz2
  2. Extract
  3. Then run the following
BASE_BSP="$(realpath $tegra_dir)"
ToT_BSP="$BASE_BSP"
TARGET_BSP="$ToT_BSP"
keys_path=/mnt/keys/
secureboot_params+=(-u "$keys_path"/pkc.pem)
secureboot_params+=(-v "$keys_path"/sbk)

pushd "$TARGET_BSP" || die "Cannot switch to TARGET_BSP:$TARGET_BSP"
./tools/ota_tools/version_upgrade/build_base_recovery_image.sh \
        "${secureboot_params[@]}" \
        jetson-xavier-nx-devkit-emmc R32-6 "${BASE_BSP}" "${BASE_BSP}/rootfs" "${TARGET_BSP}" ||
                die "Cannot generate recovery image"

./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh \
        "${secureboot_params[@]}" \
        jetson-xavier-nx-devkit-emmc R32-6 || die "Could not generate update package"

Note: that I have to use R32-6 because it does not seem that 32-7 is a valid entry for the OTA scripts:

$ grep -ri r32-6 work/Linux_for_Tegra/tools/ota_tools/version_upgrade/
work/Linux_for_Tegra/tools/ota_tools/version_upgrade/Image_based_OTA_Examples.txt:-_BASE_VERSIONS_NO_LAYOUT_CHANGE=( "R32-3" "R32-4" "R32-5" "R32-6" )
work/Linux_for_Tegra/tools/ota_tools/version_upgrade/Image_based_OTA_Examples.txt:+_BASE_VERSIONS_NO_LAYOUT_CHANGE=( "R32-3" "R32-5" "R32-6" )
work/Linux_for_Tegra/tools/ota_tools/version_upgrade/Image_based_OTA_Examples.txt:      echo -ne "\t\t<bsp version>: the version of the base BSP. Supported versions:R28-2, R28-3, R28-4, R32-1, R32-2, R32-3, R32-4, R32-5, R32-6;\n"
work/Linux_for_Tegra/tools/ota_tools/version_upgrade/nv_ota_common.func:_BASE_VERSIONS_NO_LAYOUT_CHANGE=( "R32-3" "R32-4" "R32-5" "R32-6" )
work/Linux_for_Tegra/tools/ota_tools/version_upgrade/build_base_recovery_image.sh:      echo -ne "\t   supported versions: R28-2, R28-3, R28-4, R32-1, R32-2, R32-3, R32-4, R32-5, R32-6\n"
work/Linux_for_Tegra/tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh:       echo -ne "\t\t<bsp version>: the version of the base BSP. Supported versions:R28-2, R28-3, R28-4, R32-1, R32-2, R32-3, R32-4, R32-5, R32-6;\n"
$ grep -ri r32-7 work/Linux_for_Tegra/tools/ota_tools/version_upgrade/
$
  • Yes, the EKB partition has been updated with the kek2 keys, field vector and symmetric keys
11

hello user141301,

sorry, I got confirmation that Image-based OTA does not support the case of disk encryption enabled. I will also revise my previous comments to avoid confusion.

furthermore,
if you’ve enables PKC/SBK, you may use r32.7.3 to do image-based OTA because the image-based OTA tools before r32.7.3 has some issues on supporting PKC/SBK.

12

Ah okay understood. Is there any path/timeline to image OTA with disk encryption being supported?

So to do image OTA with secure-boot enabled (no disk encryption) i have to use 32.7.3 correct?

13

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.