GPU Firmware Explained: VBIOS, GSP, Signed Microcode and Updates

GPU firmware is the code that runs on a graphics card or accelerator before and alongside the driver: a VBIOS (with a UEFI display driver) stored in flash on the board, plus signed microcode for a dozen small on-chip processors that the driver loads from files such as those in /lib/firmware at every boot. On-chip boot ROMs check vendor signatures before that microcode runs. You update the flash part with a vendor or fwupd update, and the loaded part by updating your driver and firmware packages together.

This guide goes one level deeper than our posts on how a GPU is made, PCI option ROMs and Secure Boot and firmware updates with fwupd and LVFS. Every path, version and date below comes from the GPU makers' own documentation, the Linux kernel's driver docs (amdgpu, i915, Xe, nova), linux-firmware, fwupd and LVFS, and DMTF standards. Where a GPU maker does not publish a detail, we say so instead of guessing.

Key takeaways

• A modern GPU is a cluster of processors: besides the shader cores it carries controllers for security, power, scheduling, display and video, each with its own firmware (NVIDIA's Falcon cores and GSP, AMD's PSP and SMU, Intel's GuC, HuC, DMC and GSC).
• Firmware lives in two places. Persistent firmware (the VBIOS or IFWI image, the UEFI GOP display driver, InfoROM data) sits in flash on the board. Runtime firmware (scheduling, power and security microcode, and NVIDIA's GSP-RM) is loaded by the kernel driver from files at every boot through the kernel's request_firmware interface.
• Signature checks start in silicon: an NVIDIA Falcon boot ROM verifies "heavy secure" microcode, AMD's PSP validates firmware signatures and keeps images in a protected memory area, and Intel's GuC files carry an RSA signature checked on the GPU.
• NVIDIA moved much of its driver into firmware. The README says the GPU System Processor (GSP), first introduced with Turing, runs firmware that offloads GPU initialization and management, and that Blackwell and later GPUs are supported only by the open kernel modules, which depend on GSP. The upstream nova driver (initial code in Linux 6.15, 2025) is being built around the same model.
• Updating the board flash is a separate job from updating runtime firmware. fwupd can update some AMD discrete GPUs (applying the image to an inactive partition) and Intel discrete graphics through the GSC, while data center accelerators are often updated by vendor tools or a server's BMC through a Redfish UpdateService.
• Driver, firmware files and board firmware are a matched set. NVIDIA's open module announcement says all components of a driver stack must match versions within a release, and the kernel's own firmware guidelines exist so that new firmware files do not break older kernels.
• GPU firmware belongs in your hardware inventory next to CPU microcode and BIOS versions: it receives security fixes, and on an AI server it decides whether confidential computing attestation passes.

What firmware lives on a graphics card or accelerator?

A discrete GPU is a small computer on a PCI Express card, with its own memory, power delivery, fans and several embedded processors that bring it up before the host driver gets involved. Each processor runs firmware in the sense that matters for security: code that executes below the operating system, ships as a binary from the GPU maker, and can carry bugs only the GPU maker can fix.

NVIDIA: Falcon cores, GSP, SEC2, PMU and FSP

The kernel's nova-core documentation describes NVIDIA GPUs as embedding small RISC-like microcontrollers, called Falcon cores, that handle secure firmware tasks, initialization and power management. A GPU may have several Falcon instances, including the GSP (GPU System Processor) and SEC2 (the security engine), and may integrate a RISC-V core that can run both RISC-V and Falcon code. Each Falcon has separate instruction and data memories (IMEM and DMEM) and a small DMA engine to pull code in from system memory. The code that runs on them is called ucode.

The same documentation names a PMU (Power Management Unit) microcontroller that runs the devinit interpreter, and on Hopper and Blackwell GPUs a Foundation Security Processor (FSP), which it describes as "the GPU's Internal Root of Trust". The FSP boots from immutable ROM inside the GPU as soon as power arrives, before the host driver loads.

The NVIDIA driver README adds the GSP from the user's side: some GPUs include a GPU System Processor "which can be used to offload GPU initialization and management tasks", driven by firmware files that ship with the driver. nvidia-smi also reports an InfoROM, which its documentation describes as "a small, persistent store of configuration and state data for the GPU", with its own image version that identifies exactly which InfoROM is flashed on the board.

AMD: PSP, SMU and the command processor microengines

The amdgpu driver core documentation lists the major IP blocks on an AMD GPU. Two of them are processors that matter here. The PSP (Platform Security Processor) handles security policy, runs trusted applications, and validates and loads firmware for the other blocks. The SMU (System Management Unit) is the power management microcontroller, managing clocks, voltages, power rails, thermal limits and reset distribution for the whole chip.

Inside the graphics and compute block sit more microcontrollers: the CP microengines (ME, PFP, CE and MEC) and the RLC, which the amdgpu glossary describes as a group of general purpose helper engines involved in graphics power management and SR-IOV. The glossary also lists MES (MicroEngine Scheduler), the IMU (Integrated Management Unit) and VCN (Video Core Next) for media. Each of these consumes a firmware file. The linux-firmware WHENCE manifest we downloaded lists 699 files under amdgpu/, from the old tahiti_me.bin and tahiti_smc.bin through PSP files such as psp_14_0_2_sos.bin, psp_14_0_0_ta.bin and psp_14_0_0_toc.bin.

Intel: GuC, HuC, DMC and GSC

The i915 documentation says that from gen9 onward the hardware has three microcontrollers: the graphics microcontroller (GuC), the HEVC/H.265 microcontroller (HuC) and the display microcontroller (DMC). The GuC offloads work the host driver used to do: it authenticates the HuC, schedules graphics contexts with low latency (GuC submission) and manages GT power. The HuC handles media HEVC operations. The DMC manages display power states.

Discrete Intel GPUs add a Graphics System Controller. The i915 docs describe a GSC command streamer used for security tasks such as HDCP content protection, Protected Xe Path (PXP) and HuC firmware authentication. The fwupd Intel GSC plugin shows that the card's persistent firmware is split into FWCODE, FWDATA, OPROMCODE and OPROMDATA partitions, updated through the Intel Management Engine interface. The linux-firmware manifest even lists a per board fan control file for one discrete Intel device, xe/fan_control_8086_e20b_8086_1100.bin.

The reference table later in this post maps each of these components to where it is stored, who signs it and how it is updated. The sections in between follow the firmware from the moment power arrives to the moment the operating system is running.

How does the VBIOS initialise the card at boot?

When a PC powers on, the platform firmware enumerates PCI devices and looks for expansion ROMs. On a graphics card, that expansion ROM is the VBIOS. Microsoft's option ROM guidance gives the generic picture: option ROMs are firmware run during platform initialization, usually stored on a plug-in card, and the video BIOS on a graphics card is its first example. The PCI specification allows multiple images in the same ROM, typically a legacy x86 image and a UEFI image, and the platform firmware decides which to run.

The nova-core VBIOS documentation describes what is inside one real ROM. It uses an Ampere GA102 GPU as its example and lists four images, concatenated in the ROM and following the BIOS part of the PCI specification with NVIDIA extensions:

On Kepler and later GPUs, the docs add, the ROM begins with an Init-from-ROM (IFR) header with the signature NVGI rather than the usual PCI 0xAA55 signature, and drivers parse that header to find where the PCI images start.

The VBIOS is not only a display driver. On the GA102, the docs say, the GPU's own boot ROM firmware reads the VBIOS to bootstrap the PMU, SEC2 and GSP microcontrollers before the driver loads. The sequence they describe for Ampere is:

1. After reset, FWSEC runs on the GSP in heavy secure mode. FWSEC is described as providing "a secure boot process": it verifies firmware after a reset before loading ucode onto other microcontrollers.
2. FWSEC launches the devinit ucode on the PMU in light secure mode. Devinit is an interpreter that executes a script of register writes: programming VRAM memory controller timings, power sequencing, clock and PLL configuration, and thermal management.
3. FWSEC scrubs VRAM for ECC initialization. On consumer GPUs it scrubs part of memory and then continues asynchronously.
4. FWSEC signals completion (GFW_BOOT) and lowers privilege on some registers so the host driver can read them.
5. The kernel driver then asks FWSEC to run the FRTS command, which carves out a write protected region (WPR2) in VRAM for power management data that only heavy secure ucode can touch.

Devinit, the docs note, also has to run on suspend and resume, not only at first boot, because it is critical to power management.

AMD and Intel describe their boot sequences less publicly in kernel docs, but the model is similar: a ROM or flash image carries the earliest code, and the driver later loads runtime microcode. AMD's debugfs documentation exposes the raw VBIOS through amdgpu_vbios, "useful for verifying the contents of the video BIOS ROM", and notes that it is board specific. The amd-smi tool reports the "video bios\IFWI" information through amd-smi static --ifwi.

How does the UEFI GOP driver relate to Secure Boot?

The EFI image in the VBIOS is a UEFI driver, and UEFI Secure Boot treats it like any other driver loaded from outside the protected platform flash. Microsoft's validation guidance says that drivers stored in places like option ROMs can be easily replaced and "must be verified", that signature validation for option ROMs is a hardware certification requirement, and that when Secure Boot is enabled, legacy option ROMs and the Compatibility Support Module are not allowed to run because legacy drivers cannot be authenticated.

In practice, a GOP driver whose signature matches the platform's allowed database (db) runs and you see firmware setup and the boot loader. An untrusted GOP driver is refused; Microsoft's guidance uses this as a test, emptying db so a correctly implemented firmware will not load the card's UEFI driver and the monitor stays dark until the OS driver loads. A card with only a legacy image cannot drive the display under Secure Boot at all, because the CSM is disabled.

Microsoft's guidance also says hardware vendors can get UEFI option ROMs signed through its Hardware Dev Center. Which certificate signs a given card's GOP driver is a board vendor detail; check the vendor's release notes. Our PCI option ROM post covers the db and certificate side in more depth.

Secure Boot only verifies the GOP driver that runs on the host CPU. The microcode on the GPU's own processors is verified by the GPU itself, which is the next section.

How do drivers load signed firmware blobs at runtime?

Most of the firmware a GPU needs at runtime is not on the card at all. It ships as files, and the kernel driver hands them to the GPU at every boot, resume and reset.

The Linux request_firmware interface

The kernel's firmware API documentation gives the canonical pattern: a driver calls request_firmware() with a file name and a device, copies the returned data to the device, and then calls release_firmware(). The call waits until the file is found or an error returns. The name must not contain .. path components. Variants exist for optional files (firmware_request_nowarn), for direct lookup without a user space helper (request_firmware_direct), and for falling back to a copy embedded in the platform's UEFI firmware (firmware_request_platform).

The kernel searches these paths in order, according to its documentation:

1. A custom path set with the firmware_class.path= kernel parameter (empty by default).
2. /lib/firmware/updates/ followed by the running kernel's release string.
3. /lib/firmware/updates/
4. /lib/firmware/ followed by the kernel release string.
5. /lib/firmware/

Two practical consequences follow. First, the files a driver needs early in boot must be inside the initramfs, or the driver will fail to find them before the root file system is mounted. Second, /lib/firmware/updates/ takes priority over the distribution's files, which is useful for testing a vendor fix and dangerous if someone forgets a stale file there.

Every driver declares the files it may request, and modinfo -F firmware amdgpu (or i915, xe, nouveau) prints that list.

The linux-firmware repository

Most of those files come from linux-firmware, a repository maintained alongside the kernel. Its README says it holds images extracted from older drivers plus newer images that could not ship inside a GPL work but may be redistributed separately. The rules are strict about provenance: every commit needs a Signed-off-by line from someone with "authority over the licensing of the firmware", typically at the company that owns it, and submissions from third parties without vendor involvement are not accepted. Firmware must be redistributable royalty free under the criteria in the repository's license document.

The WHENCE file is the manifest. For each driver it lists every file, often a version, and the license. Its entry for the Xe driver, for example, records xe/lnl_guc_70.bin as "GuC API/APB ver 70.72.1 for Lunarlake" and xe/bmg_huc.bin as "HuC API/APB ver 8.2.10 for Battlemage". The amdgpu files are licensed under LICENSE.amdgpu and the NVIDIA files under LICENCE.nvidia, both marked redistributable. The NVIDIA section includes GSP firmware per GPU family, such as nvidia/ga102/gsp/gsp-535.113.01.bin and nvidia/gh100/gsp/gsp-570.144.bin, alongside booter files like nvidia/tu102/gsp/booter_load-535.113.01.bin.

The kernel's firmware guidelines set the compatibility contract. Moving to a newer kernel should not force users to install newer firmware files, and updated firmware "must not cause any regressions" on older kernels. Files should carry at least a major and minor version, ideally in a header, and newer major versions must stay compatible with every kernel that loads that major number.

Why the GPU, not the driver, checks the signature

A check in the driver would only be as strong as the kernel, so GPU makers put the check inside the GPU, rooted in ROM that cannot change after manufacture.

The nova-core Falcon documentation lays out NVIDIA's chain. Falcons run code at three security levels: heavy secure (HS, also called privilege level 3), light secure (LS) and non-secure (NS). HS ucode carries a signature checked at boot, and "this signature verification is done by the hardware itself", which makes the boot ROM the root of trust. LS and NS ucode also typically carry signatures, but they are verified by HS ucode rather than by the boot ROM. The host CPU can ask a Falcon to load HS ucode, but it typically cannot load LS or NS ucode on its own. The chain on an Ampere GPU is:

Hardware boot ROM on SEC2, then the HS Booter ucode on SEC2, then the LS GSP-RM firmware on the GSP.

On Hopper and Blackwell the nova FSP documentation describes a shorter chain. The FSP boots from its own ROM, the driver sends it a Chain of Trust message containing the location of the FMC firmware, a SHA-384 hash, an RSA-3K public key and an RSA-3K signature extracted from that firmware, and the GSP boot parameters. The FSP verifies the signature and boots the FMC, which then authenticates and launches GSP-RM. There is no SEC2 Booter stage.

AMD's driver documentation gives the PSP the equivalent job: when firmware is loaded into memory, the PSP checks that it has a valid signature, then keeps the image in a protected Trusted Memory Area (TMR) so the OS or driver "can't corrupt them at runtime". The amdgpu fw_load_type module parameter exists to force direct loading for debugging on chips that support it; the default (-1) lets the driver pick the loading mode for the ASIC.

Intel's Xe firmware documentation shows the signature in the file format itself. GuC releases on all platforms, and HuC releases up to DG1, use a CSS layout: a header, the ucode, then an RSA signature, optionally followed by the key modulus and exponent. The header, ucode and RSA signature are mandatory. From DG2 and Meteor Lake, HuC and GSC binaries use a GSC layout with a Code Partition Directory and a manifest, and for the GSC blob, the docs note, the GSC's own ROM parses the headers and loads the code. The i915 docs explain how HuC is authenticated: by the GuC on older platforms, by the GSC on DG2, and in two steps (GuC for clear media, then GSC for all workloads) on Meteor Lake and newer.

None of the GPU makers publish their signing keys or full algorithms in these documents, and we do not try to fill the gap. What the docs make clear is the design intent: a file in /lib/firmware that was modified, truncated or built by someone else should be refused by the GPU, not run.

What changed when GPU makers moved driver logic into a firmware processor?

For most of Linux graphics history, the kernel driver programmed registers, managed memory, scheduled work and handled power itself. Since Turing, NVIDIA has moved much of that into GSP firmware, which reshaped how its driver is built, licensed and upstreamed.

NVIDIA's open kernel modules

NVIDIA announced on 19 May 2022 that it would publish its Linux GPU kernel modules as open source under a dual GPL and MIT license, starting with the R515 driver. The announcement said the code was production ready for data center GPUs in the Turing and Ampere families, that GeForce and workstation support was alpha quality at first, and that this was made possible by a phased rollout of the GSP driver architecture over the previous year. The user mode parts, such as CUDA, stayed closed.

The current README (we read the 580.95.05 edition) explains why the open modules need GSP. The open flavour supports Turing and later GPUs only, because the open modules depend on the GSP, which first appeared in Turing. The proprietary flavour supports Maxwell through the generation before Blackwell, and "Blackwell and later are only supported by the open kernel modules". NVIDIA recommends the open modules on all GPUs that support them.

The GSP firmware chapter of the same README lists where the files go and how to see them:

• Files named gsp_*.bin are installed in /lib/firmware/nvidia/<driver version>/, each named after a GPU architecture (for example gsp_tu10x.bin for Turing).
• GSP firmware is used by default on GPUs that support it. nvidia-smi -q shows GSP Firmware Version (a valid version when enabled, N/A when disabled), and the same line appears in /proc/driver/nvidia/gpus/<PCI bus id>/information.
• The NVreg_EnableGpuFirmware module parameter can force GSP off or on.

The coupling matters operationally. The GSP firmware version matches the driver version, so updating the driver updates the firmware that runs most of the GPU's resource management. The 2022 announcement put it plainly: all components of the driver stack must match versions within a release.

nouveau and nova in the upstream kernel

The in-tree nouveau driver can use the same GSP firmware. The 2022 announcement said nouveau could use the same firmware as the NVIDIA driver to gain features such as clock and thermal management, and linux-firmware now carries GSP images per GPU family for that purpose, as the WHENCE entries above show.

The newer upstream effort is nova. Its kernel documentation says the project consists of two drivers, nova-core and nova-drm, and is intended to replace nouveau for NVIDIA GPUs built around the GSP. nova-core is the first level driver that abstracts the GPU's hardware and firmware interfaces, as a base for nova-drm and for a vGPU manager VFIO driver. The kernelnewbies summary of Linux 6.15 lists the initial nova-core series among that release's graphics changes. The nova task list also flags a design challenge that firmware offload brings: "The GSP-RM firmware API is unstable and may incompatibly change from version to version", so the driver has to track which firmware interface version it talks to.

Intel's Xe and AMD's firmware schedulers

Intel took a similar path. The kernelnewbies notes for Linux 6.8, released on 10 March 2024, record a new Xe driver for integrated and discrete Intel GPUs from Tiger Lake onward, with its GuC firmware listed separately under xe/ in linux-firmware.

On AMD GPUs, the amdgpu docs say scheduling firmware such as MES (MicroEngine Scheduler) is responsible for loading hardware queue state in and out, which is the same kind of work moving from driver to firmware.

A dated timeline

How are graphics cards and data center accelerators updated?

There are three separate update streams, and they are often owned by three different teams.

Stream 1: runtime firmware files, with the OS

Runtime firmware updates with your operating system or driver packages. On most distributions the linux-firmware package (sometimes split by vendor) delivers the AMD, Intel and nouveau files; the NVIDIA proprietary or open driver package delivers its own GSP files under /lib/firmware/nvidia/<version>/. A new file takes effect when the driver next loads it, which in practice means a reboot, and the initramfs must be rebuilt if the driver loads early.

Stream 2: board flash, with fwupd or a vendor tool

The VBIOS or IFWI on the card changes far less often and needs a flash write. fwupd covers some of it:

• The fwupd AMD GPU plugin reports the VBIOS version of AMD APUs and can flash the IFWI of some discrete GPUs. It has reported versions since fwupd 1.8.11 and updated them since 1.9.6. The docs describe a safety design: the dGPU has two partitions, the update is written to the inactive one, the card boots the new firmware after a reboot, and if the active partition is corrupted the card may fall back to the older firmware on the inactive partition.
• The fwupd Intel GSC plugin updates the Intel graphics system controller "via the Intel Management Engine". It models FWCODE, FWDATA and option ROM code and data partitions, tracks an anti rollback security version number (arb_svn), and exposes recovery instance IDs for devices that need recovery.

fwupd only offers what vendors publish on the LVFS. The LVFS documentation describes it as "a secure web service that can be used by OEM's to upload firmware archives" and lets fwupd download metadata about updates securely. If your card's maker does not publish there, fwupd will list the device and its version but offer nothing to install. For NVIDIA and many board partners, VBIOS updates are distributed through the board maker's own tools and support pages; follow those instructions exactly and only use images published for your exact board.

Stream 3: accelerators in servers, through the BMC

Data center accelerator boards sit inside servers that already have a baseboard management controller. The DMTF Redfish UpdateService schema describes the standard interface: the update service provides methods for updating software and firmware, a FirmwareInventory collection lists components "that does not execute within a host operating system", and updates arrive through a SimpleUpdate action that fetches an image from a URI or through a multipart HTTP push.

Which accelerator components a server exposes through Redfish is up to the server and accelerator maker, so check your platform's documentation and treat it as a third update stream with its own owner.

What is firmware attestation for GPUs in confidential computing?

Confidential computing extends the trusted boundary from the CPU's encrypted virtual machine to the GPU. Before a workload sends secrets or model weights to a GPU, it wants proof that the GPU is genuine, is running known firmware, and is in confidential mode.

The DMTF Security Protocol and Data Model (SPDM) specification, version 1.3.0 dated 28 June 2023, is the industry standard for this kind of device attestation: it defines identity authentication with certificates and "firmware and configuration measurement" messages a device returns to a requester. NVIDIA's attestation documentation describes its own service layer: the NVIDIA Remote Attestation Service (NRAS) checks evidence collected from GPUs against trusted reference values and issues signed attestation tokens, with a Reference Integrity Manifest (RIM) service supplying the expected values and an OCSP service checking certificate status. The nova FSP documentation lists confidential computing mode among the device "knobs" the FSP manages, with an active value and a persistent value stored in InfoROM.

This is where firmware versions stop being housekeeping. If a GPU's VBIOS or driver firmware does not match a reference value the verifier accepts, attestation can fail and a confidential workload refuses to start. NVIDIA's attestation documentation, for example, lists an attestation advisory that applies to a specific range of driver versions (r550.0 to r550.90.12). Keep the firmware, driver and verifier policy in step.

Firmware component reference: storage, signing and updates

Step by step: inventory GPU firmware on Linux

These commands read state. None of them write firmware. The update steps at the end change firmware, so read the warnings before running them.

1. Identify the GPUs and their drivers

lspci -nnk | grep -A3 -E "VGA|3D|Display"

The Kernel driver in use line tells you whether you are on amdgpu, i915, xe, nouveau, nova or nvidia, which decides every later step.

2. See which firmware files the driver asked for this boot

journalctl -k -b | grep -i -E "firmware|guc|huc|dmc|gsp|psp|smu" | head -50
# or, without systemd journal access
sudo dmesg | grep -i firmware | head -50

Failures show up as "Direct firmware load for ... failed" lines. Intel drivers typically log the GuC, HuC and DMC files they load. Look for files loaded from /lib/firmware/updates/ that you did not expect.

3. List the files a driver may request, and which package owns them

modinfo -F firmware amdgpu | head -20
ls -l /lib/firmware/nvidia/ 2>/dev/null
ls /lib/firmware/updates/ 2>/dev/null

# Debian and Ubuntu
dpkg -S /lib/firmware/amdgpu 2>/dev/null
# Fedora, RHEL and derivatives
rpm -qf /lib/firmware/amdgpu 2>/dev/null

Some distributions compress firmware files (for example with a .zst or .xz suffix); the kernel handles that transparently.

4. Read firmware and VBIOS versions per vendor

NVIDIA (proprietary or open modules):

nvidia-smi -q | grep -E "VBIOS Version|GSP Firmware Version|Image Version|Driver Version"
cat /proc/driver/nvidia/gpus/*/information
nvidia-smi --help-query-gpu | grep -i -E "vbios|inforom"   # CSV fields for scripting

AMD with amdgpu:

sudo cat /sys/kernel/debug/dri/0/amdgpu_firmware_info
amd-smi firmware          # all GPUs, or -g <id>; add --json for scripts
amd-smi static --ifwi     # video BIOS / IFWI information, if available

The amdgpu docs say only entries with a non zero version in amdgpu_firmware_info are valid. The 0 in the path is the DRM minor number; check /sys/kernel/debug/dri/ if you have more than one GPU.

Intel with i915 or xe: the kernel log from step 2 is the most portable source for which GuC, HuC and DMC files loaded; the WHENCE manifest maps each file name to its version.

5. Ask fwupd what it can see and update

fwupdmgr get-devices
fwupdmgr refresh
fwupdmgr get-updates

get-devices lists every device fwupd recognises with its current firmware version, even if no update exists. get-updates lists only what the LVFS offers for your hardware.

Warning before any update. Applying firmware writes to the card's flash. Do it with stable power, without an overclock profile, on a machine you can recover, and only with images published for your exact board by its maker. Confirm the device first: run fwupdmgr get-devices and check that the device name, GUID and current version match the card you intend to update. Never interrupt an update.

# Only after the device check above
fwupdmgr update <device-id>
fwupdmgr get-history

For NVIDIA driver side firmware, the update is the driver package itself; for linux-firmware files, update the package and rebuild the initramfs (sudo update-initramfs -u on Debian and Ubuntu, sudo dracut -f on Fedora and RHEL), then reboot.

6. Inventory a fleet of AI servers

On a fleet, collect the same facts into one record per GPU. A minimal collection script, run by your configuration management tool, might gather:

#!/usr/bin/env bash
# Read only: saves GPU firmware facts per host for later parsing
host=$(hostname)
out=/var/tmp/gpu-fw-$host
mkdir -p "$out"
uname -r > "$out/kernel.txt"
command -v nvidia-smi >/dev/null && nvidia-smi -q -x > "$out/nvidia-smi.xml"
command -v amd-smi >/dev/null && amd-smi firmware --json > "$out/amd-firmware.json"
command -v amd-smi >/dev/null && amd-smi static --ifwi --json > "$out/amd-ifwi.json"
command -v fwupdmgr >/dev/null && fwupdmgr get-devices --json > "$out/fwupd.json"

The -x flag makes nvidia-smi print its full query as XML, which includes the VBIOS, InfoROM and GSP firmware versions. Add the BMC's view by reading the Redfish FirmwareInventory collection, so you can compare what the host sees with what the BMC reports.

Record, at minimum: GPU model and PCI ID, board part number and serial, VBIOS or IFWI version, driver version, GSP or other runtime firmware version, InfoROM image version where applicable, linux-firmware package version, and the BMC's firmware inventory entries for the accelerator.

Why GPU firmware belongs in a hardware bill of materials

A hardware bill of materials lists the components inside a device, and on an AI server the GPU is the most expensive and most firmware dense component in the box. If you cannot answer "which VBIOS and GSP versions run on our training cluster?", you cannot answer "are we affected?" when a GPU maker publishes a bulletin about either.

GPU firmware is easy to lose because it straddles hardware and software. The VBIOS is board state, visible only through vendor tools. The GSP or PSP firmware is a file in a software package that changes with every driver upgrade. The linux-firmware package is an ordinary OS dependency recorded in your image builds. The BMC's inventory is a third view that may disagree with the host.

Map all of them to one asset record. For the runtime pieces, the package versions you already pin in golden images and record in SBOMs are the authoritative source: those pins decide which GPU microcode runs. For the flash pieces, rely on host tools and the BMC.

Common mistakes

• Flashing a modified or cross flashed VBIOS. Images from forums, images for a different board with the same GPU, or images edited to change power limits are a supply chain risk you introduce yourself. At best the GPU's own secure boot refuses the microcode and the card fails to initialise; at worst you lose the UEFI display path under Secure Boot or brick the board. Use only the board maker's image for your exact board, through its tool or fwupd.
• Mixing driver and firmware versions. NVIDIA's announcement says driver components must match within a release. Leaving an old GSP file behind, or building the open modules from one release and running another release's user space, leads to load failures. On the amdgpu, i915 and xe side, running a brand new kernel against a years old linux-firmware package can mean missing files for new hardware.
• Forgetting the initramfs. A new firmware package does nothing for a driver that loads before the root file system if the initramfs still carries the old files. Rebuild it and reboot.
• Leaving stale files in /lib/firmware/updates/. That directory wins over distribution files by design. A one off test file can quietly pin you to old firmware for years.
• Treating Secure Boot as GPU firmware verification. Secure Boot checks the GOP driver on the host side. It does not verify the microcode running on the GPU's processors; the GPU does that itself.
• Ignoring BMC managed accelerator firmware. On servers, the BMC may own accelerator firmware updates, and its inventory may differ from what the host shows. If no team owns that stream, nothing gets updated.
• Updating firmware without updating the attestation policy. In confidential computing, a firmware update can change the measurements a verifier expects. Coordinate firmware rollouts with the reference values your verifier accepts.
• Assuming fwupd covers every card. It can only install what vendors publish on the LVFS. No update listed does not mean no update exists.

FAQ

What is a VBIOS on a graphics card?

The VBIOS is the firmware stored in flash on the card. According to the nova kernel docs, it is a series of concatenated images: a legacy PCI image, an EFI image containing the UEFI GOP display driver, and on NVIDIA parts, FwSec images holding signed microcode that initialises the GPU's internal processors before the driver loads.

Is GPU firmware the same as the GPU driver?

No. The driver runs on the host CPU; firmware runs on the GPU's own processors. On NVIDIA GPUs with GSP, though, the firmware ships inside the driver package and must match its version.

Where does Linux keep GPU firmware files?

Under /lib/firmware/, in vendor folders such as amdgpu/, i915/, xe/ and nvidia/. The kernel also checks /lib/firmware/updates/ first and any custom path set with firmware_class.path=. Files usually come from the linux-firmware package or, for NVIDIA's own driver, from /lib/firmware/nvidia/<driver version>/.

Are GPU firmware blobs signed?

The kernel docs for all three GPU makers describe signature checks inside the GPU. NVIDIA's heavy secure ucode carries a signature checked by the Falcon boot ROM, AMD's PSP validates firmware signatures, and Intel's GuC files carry an RSA signature in their CSS header. The GPU makers do not publish their signing keys or full schemes in those documents.

How do I check my GPU's VBIOS version on Linux?

On NVIDIA, run nvidia-smi -q and look for VBIOS Version. On AMD, use amd-smi static --ifwi, and amdgpu_firmware_info in debugfs for loaded firmware versions. On any GPU fwupd recognises, fwupdmgr get-devices shows the version.

Can fwupd update my graphics card firmware?

Sometimes. fwupd can update the IFWI of some AMD discrete GPUs (since fwupd 1.9.6) and the Intel discrete graphics system controller. It can only install firmware that the card's maker has published on the LVFS. Other cards are updated with the board maker's tool.

Why does my GPU work but the display stays blank until the OS loads with Secure Boot on?

The card's UEFI GOP driver probably was not accepted. Microsoft's guidance says that with Secure Boot enabled, legacy option ROMs cannot run and UEFI option ROM drivers must pass signature validation. A card with only a legacy VBIOS, or a GOP driver not trusted by the platform's db, shows no output until the OS driver loads.

What is GPU attestation in confidential computing?

It is a check, before secrets are released to a GPU, that the GPU is genuine and running expected firmware in confidential mode. The DMTF SPDM standard defines device identity and firmware measurement messages, and NVIDIA's attestation service compares GPU evidence against reference values and returns a signed token.

Where Safeguard fits

Safeguard does not read VBIOS versions, verify GPU microcode signatures, scan firmware images or generate hardware bills of materials, and it is not a device or endpoint management tool. The fit is indirect and sits in the software around the GPUs. The golden images that pin linux-firmware and driver packages, the container images your training and inference jobs run, the automation that rolls out drivers, and the inventory scripts that collect firmware versions are all repositories and images built from open source components. Safeguard can scan those with safeguard scan --dir ., --image <name> for a container image, or --sbom <file> for an SBOM, writing results as JSON under ./output, and the platform shows which projects contain a given component and version.

A rebuilt GPU node pulls its driver, CUDA or ROCm user space, container images and Python dependencies again, and those stacks ship open source components that receive CVEs on their own schedule. The steps below cover that software. The GPU firmware itself still has to come from the GPU maker, the board maker or your OS vendor.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos below show Safeguard on ordinary software projects, not on GPUs or firmware. They apply to the repositories and images around your GPU fleet: the image build that pins driver and firmware packages, the training and inference containers, and the scripts that collect firmware versions.

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan. The same ask, approve and test loop suits a fleet tooling repository where every change should be reviewed before it reaches a GPU node.

Click through it at your own pace, or open it full screen.

GPU clusters and their image build hosts often sit on restricted networks. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal. A runner on a build host can scan the image build tree and the training containers stored there.

Click through it at your own pace, or open it full screen.

If your team uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. An engineer can then ask about known vulnerabilities in the projects that build your GPU images, using only the tools you allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Linux kernel: Linux Firmware API
• Linux kernel: request_firmware API
• Linux kernel: Firmware search paths
• Linux kernel: Firmware guidelines
• Linux kernel: nova NVIDIA GPU drivers
• Linux kernel: nova-core VBIOS
• Linux kernel: nova-core Device Initialization (devinit)
• Linux kernel: nova-core FWSEC
• Linux kernel: nova-core Falcon
• Linux kernel: nova-core FSP and Secure Boot
• Linux kernel: nova TLV firmware images
• Linux kernel: nova-core task list
• Linux kernel: amdgpu driver core
• Linux kernel: amdgpu glossary
• Linux kernel: amdgpu debugfs
• Linux kernel: amdgpu module parameters
• Linux kernel: i915 driver
• Linux kernel: Xe firmware
• linux-firmware README
• linux-firmware WHENCE manifest
• NVIDIA driver README: GSP Firmware
• NVIDIA driver README: Open Linux Kernel Modules
• NVIDIA Technical Blog: NVIDIA Releases Open-Source GPU Kernel Modules (19 May 2022)
• NVIDIA open-gpu-kernel-modules repository
• NVIDIA nvidia-smi documentation
• NVIDIA Attestation documentation
• NVIDIA Remote Attestation Service introduction
• AMD SMI CLI tool documentation
• fwupd project
• fwupd README
• fwupd AMD GPU plugin
• fwupd Intel GSC plugin
• LVFS documentation: Introduction
• Microsoft Learn: UEFI Validation Option ROM Guidance
• DMTF Redfish UpdateService schema
• DMTF SPDM specification DSP0274 1.3.0
• kernelnewbies: Linux 6.8
• kernelnewbies: Linux 6.15

Last reviewed: 24 October 2026. GPU firmware versions, driver support lists and update tools change with every release; check your GPU maker's and board maker's current documentation before acting.