Disable recovery mode

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

From security perspective, leaving the recovery mode enabled seems like a big security hole as it allows anyone to reflash the device. Digging through the fuse configuration documentation, we found that there is a fuse bit in FUSE_RESERVED_SW_0 that can be burned to disable recovery mode.

Few questions on how that actually works:

  1. Is burning the FUSE_RESERVED_SW_0 fuse the only way to disable recovery mode? Is there any other way to disable recovery mode that does not involve blowing the fuse?
  2. For production, we are thinking of doing the fuse burning in two separate runs. First run to burn the fuses required for secure boot and second run to only burn FUSE_RESERVED_SW_0 to disable recovery mode. Any risks/concerns with this approach?
3

hello tanlu,

actually, once you’ve fused a target, you’ll need to provide the exactly same keys for running flash command-line. otherwise, it’ll abort the flashing process.

although partial fuse burning is possible, according to developer guide, Burn Fuses with the Fuse Configuration file, it recommends burning all the fuses you need in a single operation.

4

Thanks, that’s good to hear.

Btw, I noticed there is also a backup/restore feature when device is in recovery mode (Flashing Support — NVIDIA Jetson Linux Developer Guide 1 documentation). It is a good feature for debugging/developement, but could be a potential security risk. Looking at the script l4t_backup_restore.sh, there is an option to pass in the PKC key and SBK key.

Could you please confirm if these keys will be required for backup/restore on secure boot enabled devices? What will happen if someone try this without the keys?

5

We would still like to proceed with this two-step fuse burning approach. If we decide to burn the fuse to disable recovery mode, we want to run this at the very last step so that if any failures happen in between we still have access to recovery mode to reflash if necessary.

Could you please be more specific on what the risk will be so we understand the downside?

6

hello tanlu,

there’s Boot Rom communication in the early stage.
it’ll report the errors like below and abort the process if you did not given keys to the fused target.
for instance,
Error: Either RSA key file is not provided or SBK key file is provided for PKC protected target board.
however, the security of your device depends on how securely you keep the key file.

as you already know, fuse burning operations are high-risk because they cannot be reversed.
for example, a fuse value of 1 (0x01) can be changed to 3 (0x03) or 5 (0x05), once a fuse bit is set to 1, you cannot change its value back to 0. so, there’s no ways to program it to 4 (0x4) because bit 0 is already programmed to 1.

7

@JerryChang One more question: If we have disk encryption enabled, does the backup/cloning return the encrypted image or plaintext?

8

hello tanlu,

the question turned into.. why you’re going to backup an encrypted running device and restore it to another device?
it may have some security concerns.

for instance,
you should have unique ECID to enable disk encryption.
or.. you may using generic passphrase (generic-passphrase) to enable disk encryption.

anyways,
let’s have another discussion thread to follow-up your inquiries.