Fusing Orin NX on board with fuse-burn sysfs kernel interface

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
1

Jetpack version 35.6.0
Module: Orin NX 16GB

We have a product that currently uses Xavier NX as the compute board, and are in the process of releasing a new product line with Orin NX.

Now, as part of provisioning and deployment, we have a requirement in our factory process to fuse our Jetson modules with runtime scripts on-board (using the sysfs kernel interface for fusing) instead of using the USB fuse method with odmfuse.sh. This process was incorporated since Xavier and we would like to keep it for deploying our new product line with Orin NX. It appears that the /sysfs interface for Tegra 234 does not have some critical fuses in the driver - namely odm_production_mode and secure_boot_key.

My question is:
Is there a reason they were not added? Are these fuses not writable at runtime?
If we can fuse them, then how do I derive the values for FUSE_BURN_DATA? I don’t quite understand how to derive m_off, sbit and c_off values. Is there documentation on the register mapping for these fuse addresses?

ex:
FUSE_BURN_DATA(boot_security_info, 0xc7, 0, 32, 0x168, false, false),
Looking at the “Jetson Orin Fuse Specification”, i can only make sense of the size (32 bits), but not sure how to get the other values.

On a side note:
Jetpack 36 onwards, fuse-burn support from Linux has been dropped, but are we still able to back port this interface to allow fusing on-board? Or there are other things to consider and this simply wont work going forward? We really prefer a runtime method of fusing as changing our factory processes is a big hurdle.

3

hello vipul.vishnoi,

please see-also Topic 329077 Burning ReservedODM fuses in Linux,
re-cap as below..

in JP-6, we’ve deprecate and remove the fuse-burn driver, you cannot burn fuse from Linux kernel.

4

Hi Jerry,

Thank you for the response. My question is more for JP5. In the past, support was added for Tegra194 for KEK fuses How to read KEK0/1/2 Fuse values on Jetson AGX Xavier - #3 by DaneLLL. Can Nvidia provide support for the two fuses i mentioned above in this ticket for Orin NX? or share any documentation on how to derive those register/address values so i can patch the kernel driver for our application

5

hello vipul.vishnoi,

let’s check sysnodes, you should have below efuse-burn node, right?
for instance, /sys/devices/platform/efuse-burn

if yes, may I know which fuse variable you’re going to program at kernel layer.
and, what’s your board’s current authentication status.

6

Hi Jerry,

Our current board status NS (or not fused).

Yes i do have sysfs nodes for fuses

ls /sys/devices/platform/efuse-burn
boot_security_info       of_node                  reserved_odm3
debug_authentication     opt_customer_optin_fuse  reserved_odm4
driver                   opt_tpc_disable          reserved_odm5
driver_override          pdi                      reserved_odm6
ecid                     power                    reserved_odm7
modalias                 public_key               subsystem
odm_info                 reserved_odm0            uevent
odm_lock                 reserved_odm1            wakeup
odmid                    reserved_odm2

We want to be able to program odm_production_mode and secure_boot_key

Here is our current xml file with a list of fuses:

<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="SecureBootKey" size="32" value="<our sbk>" />
<fuse name="PublicKeyHash" size="64" value="<our pkc hash>" />
<fuse name="BootSecurityInfo" size="4" value="0x209" />
<fuse name="SecurityMode" size="4" value="0x1" />
</genericfuse>
7

hello vipul.vishnoi,

you should connect the device via USB port to program those two.
after the SecurityMode (also known as odm_production_mode) fuse is burned with a value of 0x1, all additional fuse write requests will be blocked.
also, SBK for encryption, if SBK is burned, then the SBKFILE users provide is for encrypting the images.

in short.
you should program reserved fuses at kernel layer only.

8

hello Jerry,

Thank you for confirming. I’m trying to understand what keys are absolutely necessary to fuse to lock down a production device. As mentioned above, we are using PKC+SBK mode for the bootloader bins.

As I understand, this means all partitions, including the eks partition (with an ekb blob that has a user auth key for UEFI variable protection + disk encryption key, etc) will be signed and encrypted. So no one should be able to decrypt the eks partition or maliciously load any firmware once the above fuses are burned. In our setup, is it necessary to fuse the OEM_K1 key to encrypt the eks partition? Is OEM_K1 only used, if someone wants to encrypt just the eks, without encrypting anything else (i.e., they don’t use SBK)? Or the purpose is to have a separation of concerns and encrypt EKB with a different key?

Are there any vulnerabilities I would miss, if i dont fuse OEM_k1?

9

hello vipul.vishnoi,

it depends-on your actual use-case.
for instance,
PKC for sign: if PKC is burned, then the KEYFILE users provide is for signing the images.
SBK for encryption: if SBK is burned, then the SBKFILE users provide is for encrypting the images.
KEKs for encryption keys: they are keys to encrypt your keys. KEK0, KEK1, KEK2 are 128-bit key files; KEK256 is 256-bit key file. please use the commands, --KEK* to determine which key encryption key you’re going to fused.

please dig into Jetson Orin Fuse Specification for more details.

11

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