Orin fuse writing error, reloaded

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

Continuing the discussion from Orin fuse writing error:

Hi,

Exact same issue here. In the first attempt, I tried to write all fuses at once, but I was not aware that I had to OR new settings of FUSE_BOOT_SECURITY_INFO with previous register content (0x1E0).

I ended up having only PKC key fused.

Then, the only progress I was able to achieve was programming bit 1 of FUSE_BOOT_SECURITY_INFO and so enabling PKC authentication. Further attempts to program the rest of keys failed.

So I tried a “step by step” approach, but no progress so far. This is my last attempt:

Given this fuse.xml content:

<genericfuse MagicId="0x45535546" version="1.0.0">  <fuse name="SecureBootKey" size="32" value="0x5ddbf98fe76494bdc8f2e9c4bca95f2a89707e70109a5079ee4d3dcbe32547d4"/>  <fuse name="BootSecurityInfo" size="4" value="0x1e9"/></genericfuse>

And using this command (where pkc.pem content corresponds to actual burned PKC fuse):

sudo ./odmfuse.sh -i 0x23 -k pkc.pem -X fuse.xml jetson-orin-nano-devkit

I got writing error, see attached UART log:

UART log 1.txt (28.4 KB)

Tried also with –force flag:

sudo ./odmfuse.sh -i 0x23 -k pkc.pem -X fuse.xml --force jetson-orin-nano-devkit

Same outcome, see attached log:

UART log 2.txt (28.4 KB)

And reading module’s fuses with this command:

sudo ./flash.sh -u pkc.pem --read-info jetson-orin-nano-devkit nvme0n1p1

Gives me this output:

==== Fuse Info (/home/cet/nvidia/nvidia_36-4-4_encrypted/Linux_for_Tegra/bootloader/fuse_t234.bin) ====
PublicKeyHash: 02ee028c5dc7279fc6debaa43151455955bf0cb023a4327b33d9b288d9108878748822a01da0147a87631c79ef4357ea61d38d4c3577ba534049d2f056646675
PkcPubkeyHash1: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
PkcPubkeyHash2: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
BootSecurityInfo: 000001e1
ArmJtagDisable: 00000000
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmInfo: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000
Sku: 000000d3
Uid: 800200190000001401f45d7004000000
OptEmcDisable: 00000000

Any hints?

Thanks

4

hello hen77,

this looks you’ve a board fused with PKC key, and its key format as 3072-bit RSA.

5

Hi JerryChang,

Sure, unfortunately now I need to program other fuses, and that does not work: see my first post for what I’ve tried to do.

6

hello hen77,

as mentioned by developer guide, Burn Fuses with the Fuse Configuration file.

NVIDIA recommends burning all the fuses you need in a single operation

let’s check BR_CID reported from your flash messages, which contain the info of your secureboot authentication scheme.

besides,
you should also enable ODM key valid (bit-9 of BootSecurityInfo) when the boot image authentication by PKC and decryption by SBK.
FYI, the “OemKeyValid” bit in fuse “BootSecurityInfo” (not SecurityMode) controls if the boot images need to be encrypted/signed or not.

7

Hello JerryChang,

That’s what I’ve tried to do in the first place, with this fuse.xml (actual keys omitted for clarity):

<genericfuse MagicId="0x45535546" version="1.0.0">
	<fuse name="PublicKeyHash" size="64" value="${PKC_KEY_HASH}"/>
	<fuse name="SecureBootKey" size="32" value="${SBK_KEY}"/>
	<fuse name="OemK1" size="32" value="${K1_KEY}"/>
	<fuse name="OemK2" size="32" value="${K2_KEY}"/>
	<fuse name="BootSecurityInfo" size="4" value="0x209"/>
</genericfuse>

But only PKC key got programmed. Unfortunately I don’t have an UART log of that attempt.

After that, I found that I had to OR new settings of FUSE_BOOT_SECURITY_INFO with previous register content (0x1E0). So I tried to program various register/command combinations. All I was able to get is programing bit 1 of FUSE_BOOT_SECURITY_INFO, using this fuse.xml:

<genericfuse MagicId="0x45535546" version="1.0.0">
	<fuse name="PublicKeyHash" size="64" value="${PKCS_KEY_XML_HASH}"/>
	<fuse name="BootSecurityInfo" size="4" value="0x1e1"/>
</genericfuse>

That succesfullty enabled PKC authentication, as can be seen from flash.sh output:

sudo ./flash.sh -u pkc.pem --read-info jetson-orin-nano-devkit nvme0n1p1
###############################################################################
# L4T BSP Information:
# R36 , REVISION: 4.4
# User release: 0.0
###############################################################################
ECID is 0x81012344705DF4011400000019000280
# Target Board Information:
# Name: jetson-orin-nano-devkit, Board Family: generic, SoC: Tegra 234, 
# OpMode: production, Boot Authentication: PKC, 
# Disk encryption: disabled ,
###############################################################################

...

From then on, I had to add -k pkc.pem to odmfuse commands to get them executed (and that’s correct), but still cannot program any other fuse.

As I wrote, last (and simplest) try was to program SBK fuse with this configuration:

<genericfuse MagicId="0x45535546" version="1.0.0">
	<fuse name="SecureBootKey" size="32" value="${SBK_KEY_XML}"/>
	<fuse name="BootSecurityInfo" size="4" value="0x1e9"/>
</genericfuse>

And checking UART log, I got this error (full logs attached to my first post):

I> Burning fuses
I> 1. Start SecureBootKey burn
E> FUSE: Failed to burn fuse addr: 0x2fe.
E> FUSE: Could not write Fuse: 0x66.
E> FUSE: Could not write Fuse: 0x66.
E> FUSE: Failed burn fuses as per fuse info.
E> FSKP: Failed to burn fuses.
C> Task 0x0 failed (err: 0x62170302)
E> Top caller module: FSKP, error module: FUSE, reason: 0x02, aux_info: 0x03
I> Busy Spin

What does that error codes mean? Is this outcome expected, and in that case, why? What I have to do to write other fuse keys?

Thanks

8

please share BR_CID, it’s reported from your host machine.

9

Is BR_CID obtainable from ECID?

Board ID(3767) version(301) sku(0000) revision(G.1)
Preset RAMCODE is 1
Chip SKU(00:00:00:D3) ramcode(1) fuselevel(fuselevel_production) board_FAB(301)
ECID is 0x81012344705DF4011400000019000280

edit: I got BR_CID (same as ECID?) with this command:

sudo ./bootloader/tegrarcm_v2 --chip 0x23 --uid
BR_CID: 0x81012344705DF4011400000019000280
10

hello hen77,

BR_CID composed by 4 ECIDs. according to above, it looks it’s a PKC fused target.
however, fuse read will not report SBK key, that is expected due to security concern.

according to above, it’s likely you’ve SBK keys fused onto this target.
so.. let’s check you’re able to re-flash this target with only PKC key.

11

hello JerryChang,

I’ve succesfully re-flashed the target with root filesystem encryption enabled; I used default (zero) keys for OEM_K1, kernel encryption and UEFI authentication, and random generated key for disk encryption. Passphrase has been recalculated at boot time (I used option --generic-passphrase for rootfs creation).

12

hello hen77,

disk encryption, UEFI authentication has nothing to do with the bootloader secureboot.
as long as you don’t see BootRom communication failed, you’re using the identical keys.

so..
let’s give it another try with below fuse.xml file.

<genericfuse MagicId="0x45535546" version="1.0.0">
	<fuse name="PscOdmStatic" size="4" value="0x00000060"/>
	<fuse name="SecureBootKey" size="32" value="${SBK_KEY}"/>
	<fuse name="OemK1" size="32" value="${K1_KEY}"/>
	<fuse name="OemK2" size="32" value="${K2_KEY}"/>
	<fuse name="BootSecurityInfo" size="4" value="0x2e9"/>
</genericfuse>

please try below fuse commands for confirmation.
$ sudo ./odmfuse.sh -X <fuse_config> -i 0x23 -k <pkc.pem> <target_config>

13

Hello JerryChang,

I tried below command:

sudo ./odmfuse.sh -X fuse.xml -i 0x23 -k pkc.pem jetson-orin-nano-devkit

with below fuse.xml file:

<genericfuse MagicId="0x45535546" version="1.0.0">
  <fuse name="PscOdmStatic" size="4" value="0x00000060"/>
  <fuse name="SecureBootKey" size="32" value="0x5ddbf98fe76494bdc8f2e9c4bca95f2a89707e70109a5079ee4d3dcbe32547d4"/>
  <fuse name="OemK1" size="32" value="0xa70a1fbffc782fffc5cff5a7df1a98d96dd598d69c386c71ffd999bebd744252"/>
  <fuse name="OemK2" size="32" value="0x15d9a88025ce91d03cb879a4369dc91a13ee40dbf13dd2f7956b974683bede0d"/>
  <fuse name="BootSecurityInfo" size="4" value="0x2e9"/>
</genericfuse>

and got attached UART log:

Fuse log.txt (28.6 KB)

in particular,

I> Task: Crypto init
I> Task: Program CBB PCIE AMAP regions
I> Task: Burn fuses
I> Index : 1    PscOdmStatic    size: 4
I> Index : 2    SecureBootKey    size: 32
I> Index : 3    OemK1    size: 32
I> Index : 4    OemK2    size: 32
I> Index : 5    BootSecurityInfo    size: 4
I> Fuse Blob found
I>
I> Burning fuses
I> 1. Start PscOdmStatic burn
I> 1. PscOdmStatic burnt successfully
W> No handling of CRC-32 for PscOdmStatic
I>
I> 2. Start SecureBootKey burn
E> FUSE: Failed to burn fuse addr: 0x2fe.
E> FUSE: Could not write Fuse: 0x66.
E> FUSE: Could not write Fuse: 0x66.
E> FUSE: Failed burn fuses as per fuse info.
E> FSKP: Failed to burn fuses.
C> Task 0x0 failed (err: 0x62170302)
E> Top caller module: FSKP, error module: FUSE, reason: 0x02, aux_info: 0x03
I> Busy Spin

Thanks

P.S. What is the meaning of 0110b for OEM_K2_PURPOSE?

14

hello hen77,

it might due to your 1st fuse burn process has those keys written to modules (i.e. PKC/SBK/OEM_K1/OEM_K2)
however, the fuse burning process has abort due to BootSecurityInfo mismatched.
it is impossible to read SBK, OEM_K1/K2 due to security concerns.


please give it a try with below fuse.xml file to burn your target again,
let’s removing all those keys since they’ve already written to the module.
for instance,

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

accordind to.. BootSecurityInfo: 000001e1
you’ll need to execute odmfuse with below to fuse this target.
sudo ./odmfuse.sh -X fuse.xml -i 0x23 -k pkc.pem jetson-orin-nano-devkit

let’s give it a try, thanks

15

Hello JerryChang,

I’ve done the test, using this xml file:

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

and this command:

sudo ./odmfuse.sh -X fuse.xml -i 0x23 -k pkc.pem jetson-orin-nano-devkit

this time I got another kind of error:

Fuse log 2.txt (28.4 KB)

in particular,

I> FSKP (version: 0.0.0.0-t234-54845784-33c9168e)
I> t234-A01-1-Silicon (0x12347)
I> Emulation:
I> Entry timestamp: 0x00975330
I> Regular heap: [base:0x40040000, size:0x10000]
I> DMA heap: [base:0x473800000, size:0x800000]
I> Task: Crypto init
I> Task: Program CBB PCIE AMAP regions
I> Task: Burn fuses
I> Index : 1    BootSecurityInfo    size: 4
I> Fuse Blob found
I>
I> Burning fuses
I> 1. Start BootSecurityInfo burn
E> FUSE: Failed to reset bit: 0, for fuse: 0x0.
E> FUSE: Could not write Fuse: 0x0.
E> FUSE: Could not write Fuse: 0x0.
E> FUSE: Failed burn fuses as per fuse info.
E> FSKP: Failed to burn fuses.
C> Task 0x0 failed (err: 0x62170413)
E> Top caller module: FSKP, error module: FUSE, reason: 0x13, aux_info: 0x04
I> Busy Spin

then I read fuses with usual command

sudo ./flash.sh -u pkc.pem --read-info jetson-orin-nano-devkit nvme0n1p1

and this is the actual status of the [readable] fuses:

###############################################################################
# L4T BSP Information:
# R36 , REVISION: 4.4
# User release: 0.0
###############################################################################
ECID is 0x81012344705DF4011400000019000280
# Target Board Information:
# Name: jetson-orin-nano-devkit, Board Family: generic, SoC: Tegra 234, 
# OpMode: production, Boot Authentication: PKC, 
# Disk encryption: disabled ,
###############################################################################

... [part of log omitted] ...

Board ID(3767) version(301) sku(0000) revision(G.1)
Preset RAMCODE is 1
Chip SKU(00:00:00:D3) ramcode(1) fuselevel(fuselevel_production) board_FAB(301)
ECID is 0x81012344705DF4011400000019000280

==== Fuse Info (/home/cet/nvidia/nvidia_36-4-4_encrypted/Linux_for_Tegra/bootloader/fuse_t234.bin) ====
PublicKeyHash: 02ee028c5dc7279fc6debaa43151455955bf0cb023a4327b33d9b288d9108878748822a01da0147a87631c79ef4357ea61d38d4c3577ba534049d2f056646675
PkcPubkeyHash1: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
PkcPubkeyHash2: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
BootSecurityInfo: 000001e1
ArmJtagDisable: 00000000
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmInfo: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000
Sku: 000000d3
Uid: 800200190000001401f45d7004000000
OptEmcDisable: 00000000

To be sure, I rechecked fuse.xml contents and did again whole procedure, but I got same results.

Thanks

16

hello hen77,

may bad.. I miscalculate the value. you should have 0x209 OR 0x1E0.
let’s test with BootSecurityInfo=0x3E9.

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

My bad too… I didn’t check enough!

Tried with 0x3E9, success:

I> FSKP (version: 0.0.0.0-t234-54845784-33c9168e)
I> t234-A01-1-Silicon (0x12347)
I> Emulation:
I> Entry timestamp: 0x0098e8c5
I> Regular heap: [base:0x40040000, size:0x10000]
I> DMA heap: [base:0x473800000, size:0x800000]
I> Task: Crypto init
I> Task: Program CBB PCIE AMAP regions
I> Task: Burn fuses
I> Index : 1    BootSecurityInfo    size: 4
I> Fuse Blob found
I>
I> Burning fuses
I> 1. Start BootSecurityInfo burn
I> 1. BootSecurityInfo burnt successfully
W> No handling of CRC-32 for BootSecurityInfo
I>
I> Successfully burnt fuses as per fuse info
I> Index : 1    BootSecurityInfo    size: 4
I> Fuse Blob found
I> No RPMB provisioning details is found. Skip RPMB Provisioning.
I> FSKP finished

Now boot authentication is SBK + PKC, correctly. And luckily SBK key was correctly burned, because flash.sh accepted original sbk.key:

###############################################################################
# L4T BSP Information:
# R36 , REVISION: 4.4
# User release: 0.0
###############################################################################
ECID is 0xA9012344705DF4011400000019000280
# Target Board Information:
# Name: jetson-orin-nano-devkit, Board Family: generic, SoC: Tegra 234, 
# OpMode: production, Boot Authentication: SBKPKC, 
# Disk encryption: disabled ,
###############################################################################

... [part of log omitted] ...

==== Fuse Info (/home/cet/nvidia/nvidia_36-4-4_encrypted/Linux_for_Tegra/bootloader/fuse_t234.bin) ====
PublicKeyHash: 02ee028c5dc7279fc6debaa43151455955bf0cb023a4327b33d9b288d9108878748822a01da0147a87631c79ef4357ea61d38d4c3577ba534049d2f056646675
PkcPubkeyHash1: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
PkcPubkeyHash2: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
BootSecurityInfo: 000003e9
ArmJtagDisable: 00000000
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmInfo: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000
Sku: 000000d3
Uid: 800200190000001401f45d7004000000
OptEmcDisable: 00000000

So to recap, while a readable key such as PKC can be successfully “rewritten” (virtually, because the fusing process checks actual register contents and skips overwrite if source data has the same value), every attempt to rewrite a write-only key such as SBK will fail, even if the content is actually the same as the source data, not because it could not be written but because it can not be checked.

In my opinion the disappointing thing is that, having a programmable FUSE_SECURITY_MODE_0 OTP flag that disables register readback, there should be no necessity to have some keys permanently write-only.

Thanks

18

hello hen77,

it’ll be vulnerability to reveal encryption keys, (i.e. SBK, OEM_K1, OEM_K2).
as mentioned by developer guide, it’s the suggestion to avoid such scenario.

NVIDIA recommends burning all the fuses you need in a single operation.

anyways,

thanks for status sharing, glad to know it works.
I’ve also update my previous post #14 to revise BootSecurityInfo accordingly.

19

Hello JerryChang,

Now I’ve tred to write OEM K1 and K2 keys with this configuration XML:

<genericfuse MagicId="0x45535546" version="1.0.0">
	<fuse name="OemK1" size="32" value="${K1_KEY}"/>
	<fuse name="OemK2" size="32" value="${K2_KEY}"/>
</genericfuse>

And got this error:

I> FSKP (version: 0.0.0.0-t234-54845784-33c9168e)
I> t234-A01-1-Silicon (0x12347)
I> Emulation:
I> Entry timestamp: 0x00b95b28
I> Regular heap: [base:0x40040000, size:0x10000]
I> DMA heap: [base:0x473800000, size:0x800000]
I> Task: Crypto init
I> Task: Program CBB PCIE AMAP regions
I> Task: Burn fuses
I> Index : 1    OemK1    size: 32
I> Index : 2    OemK2    size: 32
I> Fuse Blob found
I>
I> Burning fuses
I> 1. Start OemK1 burn
E> FUSE: Failed to burn fuse addr: 0x316.
E> FUSE: Could not write Fuse: 0x6a.
E> FUSE: Could not write Fuse: 0x6a.
E> FUSE: Failed burn fuses as per fuse info.
E> FSKP: Failed to burn fuses.
C> Task 0x0 failed (err: 0x62170302)
E> Top caller module: FSKP, error module: FUSE, reason: 0x02, aux_info: 0x03
I> Busy Spin

I suppose that, following the same behavior of SBK programming operations, I got error because the keys have already been fused (or at least OEM K1 key). Am I right?

Thanks

20

as mentioned, those keys has written to modules (i.e. PKC/SBK/OEM_K1/OEM_K2) in your 1st fuse burning process.

21

Hello JerryChang,

After enabling PKC + SBK authentication, I am facing two issues:

  1. With actual contents of SPI flash, module remains in recovery mode. This is expected, I think; so I rebuilt the flash images and tried to reflash, but got stuck in issue 2:

  2. Flashing using command:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -u pkc.pem -v sbk.key --network usb0 --flash-only

fails with “ERROR: might be timeout in USB write” during “sending bct_br” or “sending blob”, depending on the USB port used.

Never happened before enabling secure boot. Same PC, same port, same USB cable.
(in fact, you’ll remember I successfully reflashed the module some days ago: Orin fuse writing error, reloaded - #11 by hen77)

Note: I’ve already tried all the tricks from here:

Tried also other USB cables/ports/adding USB hubs. No success.

Do you know any possible solution?

Thanks

22

hello hen77,

--flash-only options to flash the image created aforehand.
please try build from scratch to have image creation and image flashing.
for instance,
here’s image flash command based-on fused Orin-NX.
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -u PKC.pem -v SBK.key -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key --showlogs --network usb0 jetson-orin-nano-devkit internal