Secure Boot & Secure UEFI

Robotics & Edge Computing Jetson Systems Jetson Orin NX
,
1

Hi,

I’ve been familiarizing myself with NVIDIA Orin NX r36.5 boot loading process. My goal is to make a resilient boot process - from BootROM → UEFI → Kernel. Based on my current understanding the BootROM is all on the SoC. As booting progresses to the Slot A/B M1 → M2 it loads the BCT from storage - where is that information stored? In the rootfs?

I’m concerned about data corruption with my usecase. My thought was to implement a checksum before the M1 step if that’s possible to validate the areas memory that will be susceptible to corruption. My next question would be does Secure Boot & Secure UEFI handle all of this?

2

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, I’ll address your questions and concerns about the boot loading process of NVIDIA Orin NX r365.

1. Where is the Boot Configuration Table (BCT) stored?

The BCT is stored in the storage device, not in the rootfs. The BootROM loads the BCT from the storage device, which contains the configuration settings for the boot process.

2. Data corruption concerns

Your concern about data corruption is valid, especially if you’re dealing with a use case that’s prone to data corruption. Implementing a checksum before the M1 step is a good idea to validate the areas of memory that will be susceptible to corruption.

3. Secure Boot and Secure UEFI

Secure Boot and Secure UEFI are designed to provide a secure boot process, but they don’t necessarily handle data corruption. Secure Boot ensures that only authorized firmware is loaded during the boot process, while Secure UEFI provides a secure environment for the UEFI firmware to execute.

However, Secure Boot and Secure UEFI do provide some level of protection against data corruption. For example, Secure Boot can verify the integrity of the firmware and ensure that it’s not tampered with. Secure UEFI can also provide a secure environment for the firmware to execute, which can help prevent data corruption.

4. Resilient boot process

To achieve a resilient boot process, you may want to consider implementing additional measures, such as:

  • Implementing a checksum or digital signature verification for the BCT and other critical firmware components.
  • Using a secure storage device, such as a Trusted Platform Module (TPM), to store sensitive data.
  • Implementing a robust error detection and correction mechanism to detect and correct data corruption.
  • Using a secure boot loader, such as UEFI Secure Boot, to ensure that only authorized firmware is loaded during the boot process.

Comparison with other Jetson modules

The boot loading process of NVIDIA Orin NX r365 is similar to other Jetson modules, such as Jetson AGX Orin, Jetson Xavier NX, and Jetson AGX Xavier. However, there may be some differences in the specific implementation details.

For example, Jetson AGX Orin and Jetson Orin NX use a similar boot flow, which includes BootROM, PSCROM, MB1, MB2, and UEFI. However, Jetson Xavier NX and Jetson AGX Xavier use a different boot flow, which includes BootROM, Bootloader Components, TegraBoot, and UEFI.

In summary, to achieve a resilient boot process on NVIDIA Orin NX r365, you should implement additional measures, such as checksum verification, secure storage, and robust error detection and correction. Secure Boot and Secure UEFI can provide some level of protection against data corruption, but they don’t necessarily handle data corruption.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

hello polarfiend103 ,

you may see-also developer guide, Update and Redundancy, bootloader A/B is enabled by default.
you’ll need to re-flash the target (due to different partition layouts) if you’re going to have Root File System Redundancy.

5
  1. You stated its “stored in the storage device,” what storage device? is that on the SoC where developers are not able to access that? What type of storage device is that - flash, emmc, etc?
  2. How would I go about modifying the BSP to implement a validation step before the M1 stage?
  3. You stated “Secure Boot can verify the integrity of the firmware and ensure that it’s not tampered with.” How does it do this process? Is it through a checksum or some other validation mechanism?
6

hello polarfiend103,

>> Q1
for Orin series, it’s QSPI for bootloader components.
you may see-also partition layout, such as.. $OUT/Linux_for_Tegra/bootloader/generic/cfg/flash_t234_qspi.xml for reference.

>> Q2
>> Q3
it’s bootloader secureboot to have bootloader components to be signed/encrypted to verify the integrity of the firmware.
what kinds of data corruption you concerns? it should handled by bootloader A/B.

7

The data corruption we might see is in regards to radiation. We’ll see temporary bit flip that will resolve, but there are conditions where the bit flip may persist in non-volatile memory - where we would need to correct the flip.

Below is my current understanding what functions live in the different memory units. Does secure boot check the integrity of everything that lives in QSPI_NOR? Also what do you mean by integrity of the firmware? From reading secureboot it leans more on security of the system running the right boot components but doesn’t do into detail how it checks the integrity of the firmware, which is the main component I care about

jetson_orin_nx_mapping
jetson_orin_nx_mapping1006×568 56.6 KB

8

hello polarfiend103,

secureboot, it must provide the same keys to the flash commands, and then you may write the target for bootloader binaries.
while system booting up, it’ll start with slot-A, it’ll retry (for 3-times) if the booting has failed, and then switch to slot-B to continue boot-up.