Xavier NX (eMMC) Secureboot Fusing renders devices unbootable

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
,
1

On Ubuntu 18.04, im using JetPack 4.6.2 - L4T R32.7.2

The sequence of the following commands(validation of the PKC key for signature) runs fine :

cd /tmp
wget https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/t186/jetson_linux_r32.7.2_aarch64.tbz2
wget https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/t186/tegra_linux_sample-root-filesystem_r32.7.2_aarch64.tbz2
wget https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/t186/secureboot_r32.7.2_aarch64.tbz2
cd ~
tar xvjf /tmp/Jetson_Linux_R32.7.2_aarch64.tbz2
tar xvjf /tmp/secureboot_R32.7.2_aarch64.tbz2
cd Linux_for_Tegra/rootfs/
tar xvjf /tmp/Tegra_Linux_Sample-Root-Filesystem_R32.7.2_aarch64.tbz2
cd ~/Credential_Keys
openssl genrsa -out rsa_priv.pem 2048
cd ~/Linux_for_Tegra
sudo ./odmfuse.sh -i 0x19 -k /home/citix-ai/Credential_Keys/rsa_priv.pem jetson-xavier-nx-devkit-emmc
sudo ./odmfuseread.sh -i 0x19 -k /home/citix-ai/Credential_Keys/rsa_priv.pem jetson-xavier-nx-devkit-emmc

…
[ 8.2008 ]
Fuse reading is done. The fuse values have been saved in: /home/citix-ai/Linux_for_Tegra/bootloader/fuse_info.txt
PublicKeyHash: 61f2a354fdb9b96f3626e26d8c2de60912bd17b5d46bc290a6d2e84455ccc8c1
SecureBootKey: 00000000000000000000000000000000
Kek0: 00000000000000000000000000000000
Kek1: 00000000000000000000000000000000
Kek2: 00000000000000000000000000000000
Kek256: 0000000000000000000000000000000000000000000000000000000000000000
BootSecurityInfo: 00000001
JtagDisable: 00000000
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000
ReservedOdm8: 00000000
ReservedOdm9: 00000000
ReservedOdm10: 00000000
ReservedOdm11: 00000000

mkdir -p rootfs/boot/extlinux
touch rootfs/boot/extlinux/extlinux.conf
sudo ./flash.sh -u /home/citix-ai/Credential_Keys/rsa_priv.pem jetson-xavier-nx-devkit-emmc mmcblk0p1
On the console :

[0742.897] I> Writing kernel-bootctrl partition.
[0742.950] I> Writing kernel-bootctrl_b partition.
[0743.053] I> Writing BCT partition.
[0743.284] I> Writing MB1_BCT partition.
[0743.574] I> Writing MB1_BCT_b partition.
[0743.870] I> Writing MEM_BCT partition.
[0745.245] I> Writing MEM_BCT_b partition.
[0746.652] I> Rebooting : reset-coldboot

▒▒▒▒Shutdown state requested 1
Rebooting system …
[0000.032] W> RATCHET: MB1 binary ratchet value 4 is too large than ratchet level 2 from HW fuses.
[0000.040] I> MB1 (prd-version: 1.5.1.9-t194-41334769-73a9b7ef)
[0000.046] I> Boot-mode: Coldboot
[0000.049] I> Chip revision : A02P
[0000.052] I> Bootrom patch version : 15 (correctly patched)
[0000.057] I> ATE fuse revision : 0x200
[0000.060] I> Ram repair fuse : 0x0
[0000.063] I> Ram Code : 0x0
[0000.066] I> rst_source : 0xb
[0000.069] I> rst_level : 0x1
[0000.072] I> Boot-device: QSPI
[0000.075] I> Qspi flash params source = brbct
[0000.079] I> Qspi using bpmp-dma
[0000.082] I> Qspi clock source : pllp
[0000.085] I> QSPI Flash Size = 32 MB
[0000.089] I> Qspi initialized successfully
[0000.093] I> Active Boot chain : 0
[0000.096] I> Boot-device: QSPI
[0000.099] I> Qspi flash params source = brbct
[0000.105] W> MB1_PLATFORM_CONFIG: device prod data is empty in MB1 BCT.
[0000.112] I> Temperature = 47000
[0000.115] W> Skipping boost for clk: BPMP_CPU_NIC
…

The sequence of the following commands(validation of the SBK key to encrypt) fails :

cd /tmp
wget https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/t186/jetson_linux_r32.7.2_aarch64.tbz2
wget https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/t186/tegra_linux_sample-root-filesystem_r32.7.2_aarch64.tbz2
wget https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/t186/secureboot_r32.7.2_aarch64.tbz2
cd ~
tar xvjf /tmp/Jetson_Linux_R32.7.2_aarch64.tbz2
tar xvjf /tmp/secureboot_R32.7.2_aarch64.tbz2
cd Linux_for_Tegra/rootfs/
tar xvjf /tmp/Tegra_Linux_Sample-Root-Filesystem_R32.7.2_aarch64.tbz2
cd ~/Credential_Keys
openssl genrsa -out rsa_priv.pem 2048
cat >skb_file.key <<EOF
123456789abcdef0fedcba9876543210
EOF
cd ~/Linux_for_Tegra
sudo ./odmfuse.sh -i 0x19 -k /home/citix-ai/Credential_Keys/rsa_priv.pem -S /home/citix-ai/Credential_Keys/skb_file.key jetson-xavier-nx-devkit-emmc
sudo ./odmfuseread.sh -i 0x19 -k /home/citix-ai/Credential_Keys/rsa_priv.pem -S /home/citix-ai/Credential_Keys/skb_file.key jetson-xavier-nx-devkit-emmc

…
[ 8.0602 ]
Fuse reading is done. The fuse values have been saved in: /home/citix-ai/Linux_for_Tegra/bootloader/fuse_info.txt
PublicKeyHash: 61f2a354fdb9b96f3626e26d8c2de60912bd17b5d46bc290a6d2e84455ccc8c1
SecureBootKey: 123456789abcdef0fedcba9876543210
Kek0: 00000000000000000000000000000000
Kek1: 00000000000000000000000000000000
Kek2: 00000000000000000000000000000000
Kek256: 0000000000000000000000000000000000000000000000000000000000000000
BootSecurityInfo: 00000005
JtagDisable: 00000000
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000
ReservedOdm8: 00000000
ReservedOdm9: 00000000
ReservedOdm10: 00000000
ReservedOdm11: 00000000

mkdir -p rootfs/boot/extlinux
touch rootfs/boot/extlinux/extlinux.conf
sudo ./flash.sh -u /home/citix-ai/Credential_Keys/rsa_priv.pem -v /home/citix-ai/Credential_Keys/skb_file.key jetson-xavier-nx-devkit-emmc mmcblk0p1
On the console :

[0742.897] I> Writing kernel-bootctrl partition.
[0742.950] I> Writing kernel-bootctrl_b partition.
[0743.053] I> Writing BCT partition.
[0743.284] I> Writing MB1_BCT partition.
[0743.574] I> Writing MB1_BCT_b partition.
[0743.870] I> Writing MEM_BCT partition.
[0745.245] I> Writing MEM_BCT_b partition.
[0746.652] I> Rebooting : reset-coldboot

▒▒▒▒Shutdown state requested 1
Rebooting system …

and nothing else.

What step did I forget to validate the SBK encryption key ?

3

hello benjamin.deuker,

it indicate the flash process is complete, and device is now booting-up.
may I know what’s the logs on the target (Xavier NX) side? could you please setup a serial console to gather bootloader logs for reference.

4

Hello JerryChang,

Here are the complete logs on the host side (host.log)
host.log (120.9 KB)

and on the target side (xavier-nx.log).
xavier-nx.log (14.4 KB)

5 
[0347.233] I> Erasing device 3: 0
[0347.241] I> QSPI: Erasing entire device
[0408.271] I> Writing device 3: 0.
[0408.400] I> Found 47 partitions in QSPI_FLASH (instance 0)
[0408.428] I> Erasing device 1: 3
[0409.056] I> Writing device 1: 3.
[0409.101] I> Writing device 1: 3.
[0409.137] I> Found 11 partitions in SDMMC_USER (instance 3)
[0409.162] I> Writing device 1: 3.
[0409.197] I> Found 11 partitions in SDMMC_USER (instance 3)
[0409.221] I> Writing mb1 partition.
[0410.874] I> Writing mb1_b partition.
[0412.528] I> Writing spe-fw partition.
...
[1057.389] I> Rebooting : reset-coldboot


▒▒▒▒Shutdown state requested 1
Rebooting system ...

hello benjamin.deuker,

that’s log to full flash the target. what’s the logs for the next boot-up cycle?

6

There is no next boot-up cycle with SBK. The target is continuously in recovery mode.

Here is the complete log on the target side PKC only, witout SBK
target_pkc_only.log (109.0 KB)

on the host side PKC only, witout SBK
host_pkc_only.log (72.0 KB)

7

hello benjamin.deuker,

I doubt your 2nd approach is wrong, and the SBK key did not burn to the target. Due to the device is already fused with PKC, you cannot running odmfuse script for the fuse burning to assign PKC key again.

here’s also an FYI,
Any binaries loaded before CBoot are encrypted by SBK key.
Any binaries loaded by CBoot are encrypted by user_key, the user_key is specified in eks.img. An user_key is purely software, user can define it; 0 user_key means no encryption.

BTW,
you may see-also related Topic 208426 for Fuse Burning,

8

Hello JerryChang,

First:
If the odmfuseread.sh utility does not read the target state what is it good for?

Second:
The two approaches are done on two different targets.

My question is only about the SBK key and the encrypted MB1.
I don’t want to complicate the Xavier NX use, so well documented, with a user_key,
unless I should understand by your answer that it is not possible to use a SBK key without a user_key?

Regard

10

hello benjamin.deuker,

we’ve verified fuse burning is worked, please see-also Topic 117585 for reference,
thanks

11

Hello JerryChang,

Thank you, for confirming that your odmfuseread.sh tool is working properly.

Thanks for the link showing that the procedure works on an AGX Xavier.

But can you answer my question which is : Why the MB1 partition, is not loaded on Xavier NX?

Should I change the information
BOARDID=3668 FAB=301 BOARDSKU=0001 BOARDREV=F.0 by other values, which ones ?

Regards

12

those are board info and it should be identical with the tegraflash parsed values while you’re in the RCM mode.
as you can see… it’s shown in the beginning of flash messages… i.e.Board ID(3668) version(301) sku(0001) revision(F.0)

how about having 2-steps approaches.
for example, 1st, create the fuse blob,fuseblob.tbz2 locally. and 2nd, perform the script file, fusecmd.sh to check you could fuse the board correctly.
furthermore, you may also running flash script by adding --no-flash to create image blob. and, second step to execute flashcmd.txt for image flashing.

13

I changed the procedure with a new target :

cd /tmp
wget https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/t186/jetson_linux_r32.7.2_aarch64.tbz2
wget https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/t186/tegra_linux_sample-root-filesystem_r32.7.2_aarch64.tbz2
wget https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/t186/secureboot_r32.7.2_aarch64.tbz2
cd ~
tar xvjf /tmp/Jetson_Linux_R32.7.2_aarch64.tbz2
tar xvjf /tmp/secureboot_R32.7.2_aarch64.tbz2
cd Linux_for_Tegra/rootfs/
tar xvjf /tmp/Tegra_Linux_Sample-Root-Filesystem_R32.7.2_aarch64.tbz2
cd ~/Credential_Keys
openssl genrsa -out rsa_priv.pem 2048
cat >skb_file.key <<EOF
123456789abcdef0fedcba9876543210
EOF
cd ~/Linux_for_Tegra
mkdir -p rootfs/boot/extlinux
touch rootfs/boot/extlinux/extlinux.conf
sudo BOARDID=3668 FAB=301 BOARDSKU=0001 BOARDREV=F.0 ./odmfuse.sh --noburn --auth NS -i 0x19 -k /home/citix-ai/Credential_Keys/rsa_priv.pem -S /home/citix-ai/Credential_Keys/skb_file.key jetson-xavier-nx-devkit-emmc
sudo tar xpf fuseblob.tbz2
cd bootloader
sudo ./fusecmd.sh
cd …/
sudo BOARDID=3668 FAB=301 BOARDSKU=0001 BOARDREV=F.0 ./flash.sh --no-flash -u /home/citix-ai/Credential_Keys/rsa_priv.pem -v /home/citix-ai/Credential_Keys/skb_file.key jetson-xavier-nx-devkit-emmc mmcblk0p1
cd bootloader/
sudo bash ./flashcmd.txt

With exactly the same result, the MB1 sector is not loaded.

Regards

14

hello benjamin.deuker,

may I know the environment to perform fuse burning, for example, did you using ubuntu desktop?

15

I’m using ubuntu server on VMware :
https://releases.ubuntu.com/18.04/ubuntu-18.04.6-live-server-amd64.iso

16

hello benjamin.deuker,

this may be culprit.
we’ve always test with native ubuntu environment instead of virtual machine.

17

Knowing that the generation steps :

sudo BOARDID=3668 FAB=301 BOARDSKU=0001 BOARDREV=F.0 ./odmfuse.sh --noburn --auth NS -i 0x19 -k /home/citix-ai/Credential_Keys/rsa_priv.pem -S /home/citix-ai/Credential_Keys/skb_file.key jetson-xavier-nx-devkit-emmc

and

sudo BOARDID=3668 FAB=301 BOARDSKU=0001 BOARDREV=F.0 ./flash.sh --no-flash -u /home/citix-ai/Credential_Keys/rsa_priv.pem -v /home/citix-ai/Credential_Keys/skb_file.key jetson-xavier-nx-devkit-emmc mmcblk0p1

must be able to be performed in a secure environment, unlike the production steps:

sudo ./fusecmd.sh

and

sudo bash ./flashcmd.txt

I have no problem to test the production part in a native environment.
But if the secure environment can’t be virtualized, then this limit is incompatible with my project.

Can you confirm me the steps to do on a native environment?

Regards

18

hello benjamin.deuker,

as you can see in see-also thread, Topic 117585. we’ve tested and verified with native ubuntu desktop.

moreover,
you may also check Topic 117585, comment #40, there’re issues when running through VM, that’s why VM is not suggested.
if you need to work on virtualized environment, please grant the complete ownership for the USB port always, since it’ll be disconnect and reconnect many times during image flash.

19

BTW,
please see-also Topic 158361 for fuse burning Xavier NX eMMC.
we had confirmed fuse and flashing works, it based-on JetPack-4.4 for testing.
note, it’s also tested and verified with native ubuntu desktop.

20

Hello JerryChang,

I had to make some modifications to use 4.4, but the result is the same.

The following modifications were necessary:

123456789abcdef0fedcba9876543210
EOF
cat >skb_file_flash.key <<EOF
0x12345678 0x9abcdef0 0xfedcba98 0x76543210
EOF
cd ~/Linux_for_Tegra

and

sudo BOARDID=3668 FAB=301 BOARDSKU=0001 BOARDREV=F.0 ./flash.sh --no-flash -u /home/citix-ai/Credential_Keys/rsa_priv.pem -v /home/citix-ai/Credential_Keys/skb_file_flash.key jetson-xavier-nx-devkit-emmc mmcblk0p1

Regards

21

hello benjamin.deuker,

is this device flashed an release version before?
you cannot flashed with early release version due to there’s Rollback Protection through Ratcheting. it aborts the boot process if using an old version software image.

22

Hello JerryChang,

This device has indeed already been flashed, but always with the information in the following file:
tegra194-mb1-bct-ratchet-p3668.cfg (1.9 KB)
All ratchet values are zero.

Regards