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.