Ratcheting

There is a chance that the boot code may be updated due to a system flaw. It may also be possible that a security breach is identified in the software and that it is fixed in a newer version. The known vulnerabilities in the older versions of software can be leveraged by attackers to exploit the system security. Hence, the obsolete binaries must be prohibited from running on the chip.
Nonetheless, those antiquated binaries used to possess effective credentials to pass the secure boot authentication. Therefore, a version control mechanism is required to preclude the old binaries from passing the authentication so that these cannot be utilized by the attackers to exploit the system flaws. Rollback prevention checks, during the boot, the version of the software binaries against a known hardware version stored in a fuse and blocks the binaries from continuing if the software versions are found to be unacceptably old. Ratcheting is NVIDIA’s rollback prevention mechanism.
The software checks for a monotonically increasing counter in the hardware that cannot be decreased once it is increased to a certain level. Ratcheting prevents binaries designed for an old chip from executing on a new chip. But the binaries designed for a new chip can run on an old chip to maintain the backward compatibility.

Software and Hardware Ratchet Versions

Ratcheting is achieved by maintaining a version. There is a software ratchet version and a hardware ratchet version.

Software Ratchet Version

Software has this version number maintained as a part of the binary. This version number is added to the signed section of generic header that is added at the beginning of the binary. This is used to find the ratchet level of the given binary without loading and booting it.

Hardware Ratchet Version

Hardware ratchet version is a monotonically increasing counter maintained on the chip. On the SoC, there are fuses reserved to hold this value.

Ratchet Constraints

Let SW_Ratchet_Version denote the version of the software run on the chip.
Let HW_Ratchet_Version denote the version corresponding to the ratchet value from fuses.
Ratcheting has the following constraints:
If SW_Ratchet_Version < HW_Ratchet_Version : Abort boot and trigger recovery flow. This case is considered as ratchet check failure.
Ratchet check failure results in either resetting to RCM or an alternate boot chain trigger based on softfuses in BR_BCT. See Recovery Mechanism.
If SW_Ratchet_Version = HW_Ratchet_Version : Allow boot. The software is built exactly for that specific chip and, therefore, can run on the chip.
If SW_Ratchet_Version > HW_Ratchet_Version : Allow boot. Software is built for a higher version, so it has a required set of security patches applied already. In this case, it is running on an older chip, so allow it to run. In this case, updating the fuse is recommended.
Thus, older chips will continue to run new software if it is backward compatible. However, old software will not work on new chips/updated devices if the ratchet version on those devices is updated.

Opt-in Fuse

There is a dedicated fuse for opt-in. Based on its value, quickboot decides whether to perform in-field ratchet update or to skip it.
If OEM wants to opt-in for in-field ratchet update, opt-in fuse should be programmed to 1. The quickboot checks whether the opt-in fuse is burned before proceeding with the hardware ratchet update. Note that this check is software enforced only.
Opt-In Fuse Name
Bits
FUSE_OPT_CUSTOMER_OPTIN_FUSE_0 [0]
1 Bit

External Factors for Fuse Burning

The quickboot checks if the following conditions are favorable for fuse burning before actually burning the fuses.
VDD
VQPS
SoC Temperature
If all the above conditions are met, quickboot burns the fuses. If a condition is not met, it continues booting without burning the fuse and tries again on the next boot.

Software Components Protected by Ratcheting

The following software components are protected by ratcheting against any rollback attacks:
MB1
SC7 Firmware
MTS Firmware
Falcon Firmware
OEM Software Owned Components

Ratchet Levels for NVIDIA Owned Software Components

There are two sets of fuses dedicated for implementing the ratcheting for NVIDIA owned software components (i.e., NVIDIA owned ratchet fuse and OEM owned (or field) ratchet fuse).
The ratchet value for an NVIDIA owned software component is the sum of the ratchet value of NVIDIA owned ratchet fuse and OEM owned ratchet fuse.

NVIDIA Ratchet Level

The NVIDIA ratchet fuses are burned at the NVIDIA production line.
These fuses cannot be programmed from software.
For NVIDIA owned firmware, if any security loophole is found, then based on the criticality of the issue, the NVIDIA ratchet level can be updated.
An N bit NVIDIA ratchet fuse field can represent numeric value 0-2^N-1. (i.e., an absolute value is programmed in NVIDIA ratchet fuse).

OEM Ratchet Level

They are field programmable fuses and can be updated when the device is in the field.
This ratchet value is a thermometer encoded numerical value between 0 to N (i.e., number for bits set from LSB denote the fuse value).

Ratchet Level for OEM Owned Software Components

For implementing ratcheting for OEM owned software components, there are no NVIDIA owned ratchet fuses allocated. Only OEM owned ratchet fuses are allocated. The ratchet update happens in-field only.

OEM Firmware Ratchet Level

Only MB1-BCT is ratchet protected using hardware fuses.
Fuses are field programmable and can be updated when the device is in the field.
The ratchet value is thermometer encoded (a numerical value between 0 to N). For example, the number of bits set from LSB denotes the ratchet value.
Besides MB1-BCT, all OEM owned firmware loaded during boot are ratcheted using their absolute ratchet value in MB1-BCT.
OEM owned firmware ratchet versions are set in MB1-BCT and their corresponding BCH during flashing or offline image creation. For more information, see Bootburn.

Ratchet Checks

The following sections describe ratchet checks.

Ratchet Check for NVIDIA Owned Software Components

For NVIDIA owned software binary, the true hardware ratchet level is obtained by taking sum of the NVIDIA owned ratchet level and OEM owned ratchet level.
This combined ratchet level is then compared with the software ratchet version of the binary.
The ratchet check is both self-enforced and loader enforced.
Self-enforced ratchet check:
This check resides within the same code that the rollback is trying to protect. In other words, the binary that is executing performs its own ratchet check.
It is basically a self-check to ensure that older binary does not continue execution on newer systems.
Loader enforced check:
This check happens before the binary is even executed.
The ratchet version of the binary being loaded is available as part of its boot component header, making the loader capable to fully investigate the rollback status.
If any ratchet check fails in Boot ROM, recovery mode is triggered.
If any ratchet check fails in MB1, then either boot with alternate chain is triggered or the target is put into recovery mode, depending on the soft fuses for boot chain options.

Ratchet Check for MB1

Boot ROM performs the loader enforced ratchet check for MB1.
MB1 performs a self-enforced ratchet check.

Ratchet Check for SC7 Firmware

Boot ROM and MB1 perform the loader enforced ratchet check for SC7.
SC7 performs a self-enforced ratchet check.

Ratchet Check for MTS Firmware

MB1 performs the loader enforced ratchet check for MTS.
MTS performs a self-enforced ratchet check.

Ratchet Check for Falcon Firmware

Falcon firmware performs a self-enforced ratchet check.
Loader enforced ratchet check for Falcon firmware is to be determined.

Ratchet Check for OEM Owned Software Components

There is no self-enforced ratchet check available for OEM owned software components.
The loader enforced ratchet check is performed by the corresponding loader of the binaries.
Apart from MB1-BCT, all OEM owned firmware ratchet levels are set in MB1-BCT and in the Binary Component Header (BCH) while flashing the target or generating binaries offline.
The loader for the binaries compares the ratchet value of the binary in BCH too see whether it is lower or equal to its ratchet value in MB1-BCT.
MB1-BCT is the only OEM owned firmware that is hardware ratcheted using hardware fuses dedicated for MB1-BCT.

Ratchet Fuse Programming

The following sections describe ratchet fuse programming for NVIDIA owned software components.

Ratcheting for MB1/SC7 and MTS Firmware

The overall flow:
MB1 passes the ratchet version of itself and SC7-FW to the bootloader via a scratch register dedicated for MB1 and SC-FW.
MTS passes the OEM ratchet version of itself to the bootloader via a scratch register dedicated for MTS ratchet.
The bootloader compares the ratchet versions of MB1, SC7, and MTS in their corresponding scratch register with respective hardware fuse values.
Perform ratchet check and program the ratchet fuse.
For each of the binaries (MB1/SC7 and MTS), if ratchet version in scratch is greater than the hardware ratchet, then the minimum of the ratchet version of binary in boot chain A and ratchet version of binary in boot chain B is programmed in the ratchet fuse, provided the following criteria are met:
The bootloader then passes the ratchet status to guest OS. For more information, see Passing Ratchet Status to Guest OSes.
Scratch Registers
Software Component
Scratch Register
Bits
MB1
SECURE_RSV82_SCRATCH_0 [31:0]
32 Bits
SC7
SECURE_RSV98_SCRATCH_1 [31:0]
32 Bits
MTS
SECURE_RSV82_SCRATCH_1 [31:0]
32 Bits
Fuses for MB1/SC7
Fuse Ownership
Fuse Name
Bits
NVIDIA Owned
FUSE_MB1_NV_REV_0 [6:0]
7 Bits
OEM Owned (Field)
FUSE_CCPLEX_UCODE_MB1_FALCON_UCODE_FIELD_RATCHET0_0 [31:0]
32 Bits
Note that there is only one fuse allocated for storing the ratchet of both MB1 and SC7.
Fuses for MTS
Fuse Ownership
Fuse Name
Bits
NVIDIA Owned
FUSE_CCPLEX_UCODE_NV_REV_0 [6:0]
7 Bits
OEM Owned (Field)
FUSE_CCPLEX_UCODE_MB1_FALCON_UCODE_FIELD_RATCHET1_0 [31:0]
32 Bits

Ratcheting for Falcon Firmware

Falcon firmware performs a self-enforced ratchet check.
Scratch Registers
There are no scratch registers allocated for storing the Falcon firmware ratchet version. Since the ratchet check for Falcon firmware is performed by the bootloader itself, not MB1, there is no requirement for the scratch register.
Fuses for Falcon Firmware
Fuse Ownership
Fuse Name
Bits
Bits
NV Owned
FUSE_FALCON_UCODE_NV_REV_0 [2:0]
3 Bits
TSECA
FUSE_FALCON_UCODE_NV_REV_0 [4:3]
2 Bits
NVDEC
FUSE_FALCON_UCODE_NV_REV_0 [6:5]
2 Bits
TSECB
OEM Owned (Field)
FUSE_CCPLEX_UCODE_MB1_FALCON_UCODE_FIELD_RATCHET2_0 [15:0]
16 Bits
TSECA
FUSE_CCPLEX_UCODE_MB1_FALCON_UCODE_FIELD_RATCHET2_0 [31:16]
16 Bits
NVDEC
FUSE_CCPLEX_UCODE_MB1_FALCON_UCODE_FIELD_RATCHET3_0 [15:0]
16 Bits
TSECB

Ratchet Fuse Programming for OEM Owned Software Components

MB1-BCT ratchet fuse programming follows the same sequences as defined for NV Owned Firmware.
All OEM firmware (that are loaded during boot until guest ramdisk) have their ratchet version set in MB1-BCT and corresponding BCH set during flashing and during offline binaries generation. For more information about how to set the firmware ratchet version, see Bootburn.
Scratch Registers
Software Component
Scratch Register
Bits
MB1-BCT
SECURE_RSV98_SCRATCH_0 [31:0]
32 Bits
Fuses for OEM Field Ratcheting
Fuse Ownership
Fuse Name
Bits
NV Owned
N/A
N/A
OEM Owned (Field)
FUSE_RESERVED_ODM8_0 [31:0]
32 Bits
FUSE_RESERVED_ODM9_0 [31:0]
32 Bits
FUSE_RESERVED_ODM10_0 [31:0]
32 Bits
FUSE_RESERVED_ODM11_0 [31:0]
32 Bits

Passing Ratchet Status to Guest OSes

Ratchet fuse burning status is passed to guest OS via the kernel device tree. There are separate nodes for MB1, MTS, and MB1-BCT at the following location under the /proc interface.
/proc/device-tree/chosen/ratchet-status
Each node has two fields: status and error.
"error" has the appropriate ratchet error value.
"status" can have following status strings:
Ratcheting Status
Description
not_tried
Default status. Ratchet check path is skipped.
skipped_a
Active Boot Chain firmware ratchet matches with HW fuses.
skipped_b
Inactive Boot Chain firmware ratchet matches with HW fuses.
updated
Ratchet fuses are successfully updated with SW ratchet value.
failed
Ratchet fuse update(burning) failed.
no_option
Ratchet update check skipped as Opt-in fuse is not set by OEM

Lock Fuse Burning

If the SecurityMode fuse is burned, the quickboot locks fuse burning at the end of ratchet handling before kernel handoff to prevent malicious over-ratcheting.
Set bit #0 of register FUSE_DISABLEREGPROGRAM_0.