crypt_UDA: command not found / encrypted device does not start with Jetson 4.5.1

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Xavier
,
1

I tried to flash the AGX / internal mmc / with disk encryption.
The flashing process reported:

The target t186ref has been flashed successfully.
Reset the board to boot from internal eMMC.

After the reboot the AGX came up with a kernel panic:

ERROR: fail to unlock the encrypted dev /dev/mmcblk0p2.
/bin/bash: line 1: crypt_UDA: command not found
[    0.0722185] Kernel panic - not syncing: Attept to kill init! exitcode= 0x0007f00

Used SDK:
JetPack_4.5.1_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra

Used device:
*# Name: jetson-agx-xavier-devkit, Board Family: t186ref, SoC: Tegra 194, *
*# OpMode: production, Boot Authentication: NS, *
# Disk encryption: enabled ,

Used flashing command:

ROOTFS_ENC=1 ./flash.sh -i "/tmp/ekb.key" jetson-agx-xavier-devkit mmcblk0p1

Where /tmp/ekb.key contains some key not equal to “0000000”.

For flashing I followed the tutorial at:

[https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/bootloader_disk_encryption.html#wwpID0E0NE0HA](https://Flash with disk encryption)

Does anybody have this kind of issues while flashing / booting with disk encryption?

What is the solution for it?

2

Exact same behavior for Jetson JetPack_4.6_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra

4

hello nvidia935,

did you program the fuse to enable Jetson Security? you should enable disk encryption with a fused device.

6

I do not use secureboot jet - and also the fuses are not burned jet.

Backround:
I need to run my AGX in two modes:

A) open mode with no encryption for development purposes.
The root file system could be on the internal mmc or on the SDDisk

B) closed mode with disk encryption enabled - e.g. to give the device to a customer for evaluation purposes. The best solution here for me is to put the encrypted image to a SDcard and boot the AGX from there.

When I get the device back there is a need to set it back to A) (open mode) to be able to reflash it without any secure key management.

As far as I understood, using secureboot is a one way usage. It is not meant to disable the chain of trust again.

The only thing I care about for B) closed mode - is not to give the customer a chance to decrypt the root file system.
If the data of the encrypted root system is just gone for some reason- no problem.

Is there an option to achieve the switch back from B) to A) on the same device without doing weak security for B) (weak in sense of: doing the LUKS disk decryption in a unencrypted and unsigned initrd)?

7

disk encryption only enabled with a fused device. so that you’ll able to store the keys (i.e. ekb.key) securely.

8

On a fused device: Is there a possibility to boot an unsigned / unencrypted kernel?

I am also referring to Welcome — Jetson Linux<br/>Developer Guide 34.1 documentation

NVIDIA® Jetson™ Linux Driver Package (L4T) provides boot security using the Secureboot package. Secureboot prevents execution of unauthorized boot codes through chain of trust. The root-of-trust is on-die bootROM code that authenticates boot codes such as BCT, Bootloader, and warm boot vector using Public Key Cryptography (PKC) keys stored in write-once-read-multiple fuse devices. On Jetson platforms that support Secureboot Key (SBK), you can use it to encrypt Bootloader images.

9

hello nvidia935,

what did you mean “an unsigned / unencrypted kernel?”.

every bootloader binaries has sign/encrypted even without secureboot (i.e. with zero keys) you may refer to flashing logs for details. you may also check Cboot chapter for the [Kernel Boot Sequence Using extlinux.conf] as see-also, they should be unsigned/unencrypted if you load the image via file system.
however, loading binary files via filesystem has disabled if you enable Jetson security.

10

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