gpu: nova-core: correct FSP documentation
Subsystems (5)
cover gpu: nova-core: correct FSP documentation
This patch applies on top of Alexandre Courbot's GSP-FMC naming/framing fix [1].
Alexandre's patch corrects the code naming and the FMC expansion. This follow-up addresses the related documentation:
- Distinguish the roles of FSP, GSP BootROM, and GSP-FMC;
- Correct the NVDM, FRTS, and TLV terminology;
- Clarify the scope of the documented dGPU boot path and the meaning of the COT response.
[1] https://patch.msgid.link/[email protected]
Zhi Wang (1):
gpu: nova-core: correct FSP documentation
Documentation/gpu/nova/core/fsp.rst | 88 ++++++++++++++++------------- 1 file changed, 50 insertions(+), 38 deletions(-)
base-commit: d53bc149eea6213e9c4a4604df5521db7b7296ca
prerequisite-patch-id: 4ddf00f5b06d988e9c76850efe437933bd139e4c
Signature · 1 line
2.53.0
PATCH 1/1 gpu: nova-core: correct FSP secure boot documentation
The FSP documentation still blurs the roles of FSP, GSP BootROM, and GSP-FMC in the common Hopper/Blackwell dGPU boot path. It also uses incorrect expansions for NVDM and FRTS and describes GSP-FMC as an ELF image, while nova-core loads it from a TLV firmware file.
Correct those terms and show the FSP-to-GSP handoff in the existing message-flow diagram. Clarify that the COT response reports command status only, and scope the SEC2 and PRC descriptions to the dGPU platforms covered by nova-core.
Signed-off-by Zhi Wang <[email protected]>
--- Documentation/gpu/nova/core/fsp.rst | 88 ++++++++++++++++------------- 1 file changed, 50 insertions(+), 38 deletions(-)
Documentation/gpu/nova/core/fsp.rst +50 -38
@@ -3,8 +3,8 @@ =================================================== FSP (Foundation Security Processor) and Secure Boot =================================================== -This document describes the role of the FSP in the GPU boot sequence on -Hopper and Blackwell GPUs, and how it differs from the earlier Ampere boot +This document describes the role of the FSP in the common boot path for +Hopper and Blackwell dGPUs, and how it differs from the earlier Ampere boot flow. It also provides a brief overview of the PRC (Product Reconfiguration Control) protocol used to query device configuration through FSP. As with other documents in this directory, the information is subject to change and
@@ -42,18 +42,20 @@ On **Hopper/Blackwell** GPUs, FSP replaces this multi-stage process with a single message-driven interface:: FSP (hardware root of trust, boots from ROM) - -> FMC (First Mutable Code, verified by FSP) - -> GSP-RM (verified and loaded by FMC) + -> GSP BootROM + -> GSP-FMC (First Mutable Code, running on GSP) + -> GSP-RM (verified and loaded by GSP-FMC) -The driver only needs to: +At a high level, the driver: 1. Wait for FSP to complete its own secure boot (polling a scratch register). -2. Send a Chain of Trust (COT) message to FSP with the FMC firmware location, - cryptographic signatures, and GSP boot parameters. -3. FSP authenticates the FMC firmware and boots it, FMC in turn loads GSP-RM. +2. Send a Chain of Trust (COT) message to FSP with the GSP-FMC firmware + location, cryptographic signatures, and GSP boot parameters. +3. Wait for the FSP command response, then for later GSP-side boot milestones. -There is no SEC2 involvement, no Booter ucode, and no FWSEC-FRTS stage. The -entire secure boot is driven by a single FSP message exchange. +In the dGPU path described here, SEC2 and Booter ucode are not used to bring +up GSP-RM, and FWSEC-FRTS is not run as a separate stage. The driver initiates +secure boot through a single FSP message exchange. Chain of Trust (COT) protocol =============================
@@ -62,39 +64,49 @@ ensuring the GPU reaches a known, trusted state. The driver communicates with FSP using a message queue (Falcon MSGQ interface). Each message consists of an MCTP (Management Component Transport -Protocol) transport header and an NVDM (NVIDIA Vendor Defined Message) header, +Protocol) transport header and an NVDM (NVIDIA Data Model) header, followed by a protocol-specific payload. For Chain of Trust, the payload includes: -- The system memory address of the FMC firmware image. -- Cryptographic material: a SHA-384 hash, RSA-3K public key, and RSA-3K - signature extracted from the FMC ELF firmware. -- FRTS (Firmware Runtime Services) region information (vidmem offset and size). +- The system memory address of the GSP-FMC firmware image. +- Cryptographic material extracted from the GSP-FMC TLV firmware: a SHA-384 + hash, RSA-3K public key, and RSA-3K signature. +- FRTS (Firmware Runtime Security) region information (vidmem offset and size). - The system memory address of the GSP boot arguments structure. -FSP verifies the signature against the provided public key and hash, and if -verification succeeds, boots the FMC. The FMC then authenticates and launches -GSP-RM. +FSP validates the COT payload and authenticates the GSP-FMC image using the +supplied cryptographic material. It then stages the image in GSP memory and +triggers GSP BootROM. GSP BootROM authenticates and starts GSP-FMC, which then +authenticates and launches GSP-RM. The message flow is:: - nova-core FSP - | | - | 1. Poll scratch register | - | (wait for FSP boot complete) | - | | - | 2. COT message ------------> | - | (FMC addr, signatures, | - | boot params) | - | | - | |--- Verify FMC signature - | |--- Boot FMC - | |--- FMC loads GSP-RM - | | - | 3. COT response <------------ | - | (success/error) | - | | + nova-core FSP GSP + | | | + | 1. Poll scratch register | | + | (wait for FSP boot complete) | | + | | | + | 2. COT message ------------> | | + | (GSP-FMC addr, | | + | signatures, boot params) | | + | | | + | | Verify GSP-FMC | + | | signature | + | | | + | | Load GSP-FMC image | + | | -------------------->| + | | | + | | Trigger GSP BootROM | + | | -------------------->| GSP BootROM + | | | starts GSP-FMC + | 3. COT response <----------- | | GSP-FMC + | (command status) | | verifies and + | | | starts GSP-RM + | | | + +The COT response reports only the FSP command status; it does not indicate +that GSP-RM is ready. FSP message format ==================
@@ -107,7 +119,7 @@ All FSP messages share a common header format consisting of two 32-bit words: - Bits 29:28: Packet sequence number - Bits 23:16: Source Endpoint ID -**NVDM header** (NVIDIA Vendor Defined Message): +**NVDM header** (NVIDIA Data Model): - Bits 6:0: MCTP message type (0x7e = vendor-defined PCI) - Bits 23:8: PCI vendor ID (0x10de = NVIDIA)
@@ -127,9 +139,9 @@ Each knob has two values: - **Active**: the currently effective value for this boot cycle. - **Persistent**: the value stored in InfoROM, applied on subsequent boots. -The nova-core driver uses PRC to read the vGPU mode knob (object ID 0x29) -during early boot, before firmware loading, to determine whether the GPU -should operate in vGPU mode. +On Blackwell and later dGPUs, nova-core uses PRC to read the vGPU mode knob +(object ID 0x29) during early boot, before firmware loading, to determine +whether the GPU should operate in vGPU mode. The PRC message format follows the same MCTP/NVDM header structure as COT, with NVDM type 0x13. The payload contains:
Signature · 1 line
2.53.0