BootROM bug? Seek solution to recover SOM fused with SBKPKC but not OemKeyValid bit

[c.lin]

I see exactly the same problem documented here by ncs1. But that thread did not provide solution in the end.
After fusing another Jetson Orin from scratch, I found that the issue is caused by the OemKeyValid bit 9 of BootSecurityInfo.

Basically, this bit must be marked in the same fusing operation when SBK key and SBK bit (3) in BootSecurityInfo fuse.

If OemKeyValid bit is not marked while SBK key and SBK bit (3) are set, the SOM is in a bad state that will report error on mb1. Below is the log:

[ 0.6874 ] Boot Rom communication
[ 0.6877 ] tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader_encrypt.bin.signed --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed --download bct_mb1 mb1_bct_MB1_sigheader_encrypt.bct.signed
[ 0.6880 ] BR_CID: 0x89012344705DF6C70C00000002018080
[ 0.7113 ] Sending bct_br
[ 0.7114 ] Sending mb1
[ 0.7119 ] ERROR: might be timeout in USB write.
Error: Return value 3

Because of this error (OemKeyValid not set), I cannot read fuse, neither can I fuse this bit now, although I have not sealed the fuse yet. I cannot re-flash the QSPI anymore.

Would you please provide a solution for me to recover SOM from this situation?

[JerryChang]

hello c.lin,

please share the very first fuse xml file you’re used to burn fuse.
if that’s possible, please also share the logs for reference.

[c.lin]

Thanks Jerry,

Here are fuse configuration files

good_fuse_conf_with_oemkeyvalid.txt (1.2 KB)

bad_fuse_conf_without_oemkeyvalid.txt (1.2 KB)

The only difference is the bit-9 oemKeyValid bit set or not

All PKC keys are RSA-3072.

It appears to me that BootROM is in bad state: It requires host to send encrypted MB1, but it does not decrypt MB1 because of OemKeyValid is not marked. Therefore, it refuses to boot as requested from USB-C and fall back to existing boot because I have not set SecureMode to 1 yet.

I cannot read fuse from force-recovery mode, neither can I fuse OemKeyValid bit now.

I can read fuse from Linux. The PKC and BootSecurityInfo match the content from fuse-conf.xml

[JerryChang]

hello c.lin,

let’s try program the BootSecurityInfo from 0x1e9 to 0x3e9.
please refer to Burn Fuses with the Fuse Configuration file.
you should use the xml file with below..

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="BootSecurityInfo" size="4" value="0x3e9"/> 
</genericfuse>

and then, running with odmfuse script again with the same PKC/SBK you’ve burned to have additional fuses.
for instance,
$ sudo ./odmfuse.sh -X <fuse_config> -i 0x23 -k PKC -S SBK <target_config>

[c.lin]

Hi Jerry,

Thanks for your support.

It seems like we are not in sync with what the problem is.

The problem is: I cannot fuse it anymore. The mb1 sent to SOM is rejected. The host side (Linux PC) gets error “"ERROR: might be timeout in USB write.”

Here are the detailed log files:

log-on-host-side.txt (19.3 KB)

log-on-target-side.txt (36.9 KB)

current-fuse-content.txt (1.0 KB)

The fuse command & conf are exactly yours

sudo ./odmfuse.sh -X ${FUSE_CONF_XML} -i 0x23 -k ${RSA_KEY} -S ${SBK_KEY} jetson-orin-nano-devkit-super

These two threads seem to have the same problem. but they were closed without the solution in them.

Burn ODM Key Valid fuse bit on PKCSBK fused Jetson orin nano - Jetson Systems / Jetson Orin Nano - NVIDIA Developer Forums

[JerryChang]

hello c.lin,

according to BR_CID, this is target burned with 3072-bit RSA PKC, and SBK enabled.
[ 0.6331 ] BR_CID: 0x89012344705DF6C70C00000002018080

do you have OEM_K1 burn to this target yet?
if not. please try again with below xml file.

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="OemK1" size="32" value="0xXXXX"/>
    <fuse name="BootSecurityInfo" size="4" value="0x3e9"/>
</genericfuse>

[c.lin]

Hi Jerry,

The OemK1 was burnt to the target earlier. See the bad_fuse_conf_without_oemkeyvalid.txt attached.
bad_fuse_conf_without_oemkeyvalid.txt (1.2 KB)

To fuse “oem key valid” bit, I tried both cases with/without “OemK1” content in fuse conf. Neither one worked.
See the log on both host(Linux) and target(Orin) sides:
log-on-host-side-1.txt (19.3 KB)
log-on-target-side-1.txt (37.4 KB)
The re-fuse conf is here. (It’s renamed from .xml to .txt so that it can be attached here)
fuse-conf-1.txt (236 Bytes)

The error is the same: the MB1 sent from host to target is ignored by BootROM.

My guess is BootROM in one hand requires host to send encrypted MB1, while on the other hand does not decrypt the encrypted MB1 because the OemKeyValid not marked. That would cause such kind of deadlock.

BTW: Linux OS is still bootable because securemode is not set yet. If you have solution to fuse OemKeyValid bit from Linux OS, that would be good for me, too.

[c.lin]

Hi Jerry,

I dig around your(nvidia) tech support forums and found (so far) there 3 other threads (342811, 342924 and 300161) linked below.

Cannot use flash cmd after burn fuse

我使用的是Jetpack5.1.5，自制的底板，我在验证secure boot功能 我的最终目标是启用secure boot (sign + encryption) + uefi secure boot + disk encryption，因此我准备了以下的fuse <genericfuse MagicId="0x45535546" version="1.0.0"> <fuse name="PublicKeyHash" size="64" value="my key"/> <fuse name="SecureBootKey" size="32" value="my key"/> <fuse name="OemK1" size="32" value="my key"/> <fuse name="BootSecurityInfo" size="4" value="0x9"/> <!-- <fuse name="SecurityMode" size="4" value="0x0"/> --> </genericfuse> 我的第一步…

Orin NX fuse burning issue

I’m working on implementing Secure Boot on the Orin NX 8GB module, following the recommended steps # Generate a PKC Key Pair openssl genrsa -out rsa_priv.pem 3072 # Generate the Public Key (<pkc.pubkey>) and Public Key Hash (<pkc.hash>) ./tegrasign_v3.py --pubkeyhash <pkc.pubkey> <pkc.hash> --key <pkc.pem> ./Linux_for_Tegra/bootloader/tegrasign_v3.py --pubkeyhash pkc.pubkey pkc.hash --key rsa_priv.pem # Use the Generated Outputs for Secure Boot in XML # Generate a 32-byte SBK Key Use …

Jetson Orin NX - board can't flash after partial fuse burn

Hi, System: Orin NX 16G on Forecr carrier JetPack r35.5.0 What was done: I burnt my orin nx following fuses from a clean board: PKC0/1/2 with RSA3K keys SBK OEM K1/K2 Boot Security Info to 0x9 (for RSA3K+SBK) (Note that no security mode was burnt) Burn script returns success, and when I booted to my system and ran nv_fuse_read.sh I saw the PKC0/1/2 and Boot Security Info with the values I burnt. From now on, I can’t flash anything to the jetson in recovery and it always fail on pa…

They ALL point to the same problem:

OemKeyValid bit not set in first board and results in the same problem.

OemKeyValid bit set in 2nd board and works well.

There is no solution provided to recover the first board and the thread was closed.

I am seeking a solution to recover the first board. I believe this is an undocumented bug in BootROM. At a minimum, the document is misleading. OemKeyValid bit, by common sense, makes people think it is related to OemK1 & OemK2, and should NOT be related to SBC key.

[JerryChang]

hello c.lin,

please refer to previous post #5, let’s try running with odmfuse script again without given PKC/SBK keys (without -k and -S commands).
in other words, just treat the target as a NS board. for instance, $ sudo ./odmfuse.sh -X <fuse_config> -i 0x23 <target_config>

[c.lin]

Hi Jerry,

Can you please talk to your engineer team who work on BootROM or Fuse? When developers contact Nvidia, they have already exhausted all options that publicly available.

Of course, the first thing I tried was to treat the SOM like an NS board (without -k and -S command) since the “securemode” has not been set yet.

Your odmfuse.sh rejects it right away (tried both odmfuse.sh from r36.4.4 and r36.5.0):

Error: Either PKC or SBK key is not provided for SBK+PKC protected target board.

Below is the full log from Linux host:

clin@system76-USB:~/projects/Jetson-fTPM/burn-fuse/ftpm_fuse/nvidia-tech-support$ cat 04.01-burn-fuse.sh
#!/bin/bash

L4T=/Backup/projects/Jetson-Linux-36.4.4/Linux_for_Tegra/
FUSE_CONF_XML=${THISDIR}/fuse-conf.xml

pushd ${L4T}
sudo ./odmfuse.sh -X ${FUSE_CONF_XML} -i 0x23 jetson-orin-nano-devkit-super
popd

clin@system76-USB:~/projects/Jetson-fTPM/burn-fuse/ftpm_fuse/nvidia-tech-support$ cat fuse-conf.xml

clin@system76-USB:~/projects/Jetson-fTPM/burn-fuse/ftpm_fuse/nvidia-tech-support$ lsusb | grep -i nvidia
Bus 003 Device 009: ID 0955:7323 NVIDIA Corp. APX

clin@system76-USB:~/projects/Jetson-fTPM/burn-fuse/ftpm_fuse/nvidia-tech-support$ ./04.01-burn-fuse.sh
/Backup/projects/Jetson-Linux-36.4.4/Linux_for_Tegra ~/projects/Jetson-fTPM/burn-fuse/ftpm_fuse/nvidia-tech-support

Error: Either PKC or SBK key is not provided for SBK+PKC protected target board.

[JerryChang]

hello c.lin,

please try with r36.5 to replace odmfuse.func with the attachment, Topic363914_Mar24.zip (9.9 KB)
it should unblock MB1 to continue burning fuses.

[c.lin]

Hi Jerry,

Thanks for something new to try.

But did your side try that odmfuse.func you sent? It does not run.

It complains about “ECID read failed. The target board must be attached in RCM mode”. But the SOM is in “force recovery mode”.

Here is the terminal on Linus host side. (The target side is completely silent)

clin@system76-USB:/Backup/projects/Jetson-Linux-36.5.0/Linux_for_Tegra$ ls -l odmfuse*
-rw-rw-r-- 1 clin clin 35882 Mar 24 09:24 odmfuse.func
-rwx------ 1 clin clin 35882 Mar 24 09:14 odmfuse.func-from-Jerry-Chang
-rw-rw-r-- 1 clin clin 35597 Mar 24 09:24 odmfuse.func-orig
-rwxrwxr-x 1 clin clin 3348 Jan 15 22:42 odmfuseread.sh
-rwxrwxr-x 1 clin clin 36014 Mar 24 09:13 odmfuse.sh
clin@system76-USB:/Backup/projects/Jetson-Linux-36.5.0/Linux_for_Tegra$ lsusb | grep -i nvidia
Bus 003 Device 011: ID 0955:7323 NVIDIA Corp. APX
clin@system76-USB:/Backup/projects/Jetson-Linux-36.5.0/Linux_for_Tegra$ cat fuse-OemKeyValid.xml



clin@system76-USB:/Backup/projects/Jetson-Linux-36.5.0/Linux_for_Tegra$ ./odmfuse.sh -X fuse-OemKeyValid.xml -i 0x23 jetson-orin-nano-devkit-super
Error: ECID read failed.
The target board must be attached in RCM mode.
clin@system76-USB:/Backup/projects/Jetson-Linux-36.5.0/Linux_for_Tegra$

[c.lin]

Describe the problem again:

SBK key and PKC hashes are fused. BootSecurityInfo is set to 0x1e9. The OemKeyValid bit is NOT set.

The BootROM gets into buggy state: On one hand, it requires host side to send encrypted MB1. On the other hand, because OemKeyValid is not set, BootROM does not understand the encrypted MB1, therefore, it refuses to respond. That includes NOT responding the ECID query command. Therefore, your new “odmfuse.func” will NOT run (ECID is null)

[c.lin]

OK, after some hacking, I am able to fuse the OemKeyValid bit.

Now the SOM works as fused (SBKPKC).