Cannot Enable Simultaneous A/B Boot and Disk Encryption

Configuration:


I will emphasize that all configurations are stock, with no customizations.


The internal eMMC reports itself as follows:

  • Disk /dev/mmcblk0: 30785536 sectors, 14.7 GiB
  • First usable sector is 40, last usable sector is 30785503

Note that the config will use one of the following, depending on the values of the ROOTFS_AB and ROOTFS_ENC environment variables:

  • flash_l4t_t194_spi_emmc_p3668.xml
  • flash_l4t_t194_spi_emmc_p3668_rootfs_ab.xml
  • flash_l4t_t194_spi_emmc_p3668_enc_rfs.xml
  • flash_l4t_t194_spi_emmc_p3668_enc_rootfs_ab.xml

Further note that all four of these xml files have num_sectors="30777344", which is smaller than the 30785536 sectors reported by the device itself.


Successes and Failure

  • Flashing with ROOTFS_AB=0 and ROOTFS_ENC=0 succeeds
  • Flashing with ROOTFS_AB=1 and ROOTFS_ENC=0 succeeds
  • Flashing with ROOTFS_AB=0 and ROOTFS_ENC=1 succeeds
  • Flashing with ROOTFS_AB=1 and ROOTFS_ENC=1 fails
Side Note (to the above)

Adjusting the flash layout xml files so that the num_sectors matches what is reported by the hardware also fails with an identical failure mode.

-   <device type="sdmmc_user" instance="3" sector_size="512" num_sectors="30777344">
+   <device type="sdmmc_user" instance="3" sector_size="512" num_sectors="30785536">

The failure appears to be, I think, that not enough space is left on the internal eMMC for the UDA partition:

==> console.log <==
[0601.083] I> Writing rce-fw_b partition.
[0601.124] I> Writing bpmp-fw_b partition.
[0601.185] I> Writing bpmp-fw-dtb_b partition.
[0601.206] I> Writing kernel_b partition.
[0603.401] I> Writing kernel-dtb_b partition.
[0603.433] I> Writing recovery partition.
[0605.776] I> Writing recovery-dtb partition.
[0605.807] I> Writing esp partition.
[0608.895] I> Writing UDA partition.
[0608.923] E> NV3P_SERVER: Could not write 1048576 bytes.
==> flash.log <==
[ 486.9846 ] Writing partition kernel-dtb_b with kernel_tegra194-p3668-0001-p3509-0000.dtb [ 326723 bytes ]
[ 486.9915 ] [................................................] 100%
[ 487.0002 ] Writing partition recovery with recovery.img [ 50780160 bytes ]
[ 487.0235 ] [................................................] 100%
[ 489.3541 ] Writing partition recovery-dtb with tegra194-p3668-0001-p3509-0000.dtb.rec [ 326723 bytes ]
[ 489.3665 ] [................................................] 100%
[ 489.3755 ] Writing partition esp with esp.img [ 67108864 bytes ]
[ 489.3978 ] [................................................] 100%
[ 492.4649 ] Writing partition UDA with user_data_encrypted.img [ 27742320 bytes ]
(... hang with 3% of the UDA sent ...)

Here are the full logs:


Question: It would appear from all the documentation and the flash.sh script that Encryption + A/B Boot is supported, but somehow failing. Is this configuration supported by NVIDIA?

We have not been able to get this working with stock configurations and stock hardware, following the documentation verbatim.

hello andrew.fernandes,

just curious for the real use-case.
for example, what’s the practical use-case with root file system A/B redundancy and encrypted file system?

Hi, @JerryChang -

We will be fusing each Jetson with device-specific SBK and PKC keys, and we understand that each root filesystem will need to be individually produced, customized with KEK2 and the ECID.

We have systems that require root file system encryption and be field-upgradable, where access to the USB recovery device is not possible.

That is why we require ROOTFS_AB=1 and ROOTFS_ENC=1.

So my question is: “Is this combination officially supported by NVIDIA?” or will we have to develop a fully customized initrd and root partition LUKS encryption workflow?

Thank you!

Hi, @JerryChang - is there any official response from NVIDIA on this?

hello andrew.fernandes,

we’ve also tested with AGX Xavier platform to enable ROOTFS_AB=1 and ROOTFS_ENC=1 to confirm it works correctly.

for Xavier NX eMMC,
the root cause is that the UDA size in the flash_l4t_t194_spi_emmc_p3668_enc_rootfs_ab.xml is too large.
once enabling disk encryption, the remaining size for UDA partition is only 105885696 bytes, by setting the size of UDA to 122880000 causes the flashing failure.

hence,
you may give it a try to apply below patch to fix this issue of UDA size.
for example,

diff --git a/flash_l4t_t194_spi_emmc_p3668_enc_rfs.xml b/flash_l4t_t194_spi_emmc_p3668_enc_rfs.xml
@@ -728,7 +728,7 @@
         <partition name="UDA" type="data" encrypted="true" reencrypt="true">
             <allocation_policy> sequential </allocation_policy>
             <filesystem_type> basic </filesystem_type>
-            <size> 47689728 </size>
+            <size> 67108864 </size>
diff --git a/flash_l4t_t194_spi_emmc_p3668_enc_rootfs_ab.xml b/flash_l4t_t194_spi_emmc_p3668_enc_rootfs_ab.xml
@@ -754,7 +754,7 @@
         <partition name="UDA" type="data" encrypted="true" reencrypt="true">
             <allocation_policy> sequential </allocation_policy>
             <filesystem_type> basic </filesystem_type>
-            <size> 122880000 </size>
+            <size> 67108864 </size>

FYI,
this fix has done code review progress,
please expect next Jetpack-5.x public release version will also include this change.

I can confirm that this works on the Xavier NX DevKit.

Thank you!

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