Why Firmware Trust Is No Longer Enough
Hardware and firmware vulnerabilities have been climbing steadily in the National Vulnerability Database (NVD) for years. Secure boot—long standard on client devices—has been adapted to servers to verify that only signed firmware and bootloaders execute. But that model puts the trust anchor in the BIOS/UEFI firmware itself. If that firmware is compromised, the entire boot chain and any measured boot or remote attestation built on top of it is suspect, since the firmware performs those measurements.
Cloudflare's servers boot through a chain that starts with UEFI firmware on a motherboard flash chip, moves to Preboot Execution Environment (PXE) code on the network card, then an iPXE bootloader, and finally the Linux kernel with its initrd and root filesystem. Standard UEFI secure boot protects that chain by validating signatures against a Platform Key (PK) and a Trusted Database (DB) of allowed certificates and hashes.
Rather than relying on Microsoft's default keys, Cloudflare generates its own PK and DB entries, making itself the root of trust for UEFI. But the firmware itself still sits outside that protection.
Moving the Anchor into Silicon
AMD's Platform Secure Boot (PSB) shifts the trust anchor from firmware to hardware. The mechanism is implemented in the Platform Security Processor (PSP), an ARM Cortex-A5 microcontroller that is part of the system on chip (SoC) and cannot be modified. PSB performs three critical functions:
- Authenticates the first block of BIOS/UEFI before releasing x86 CPUs from reset
- Authenticates the System ROM contents on every boot, not just during updates
- Moves the secure boot trust chain into immutable hardware
The implementation has two components. An on-chip Boot ROM embeds a SHA384 hash of AMD's root signing key and verifies the off-chip PSP bootloader before loading it. That off-chip bootloader locates the PSP directory table, authenticates the first block of BIOS/UEFI code, and only then releases the CPUs.
AMD's root signing public key is stored as a hash value in SPI-ROM, using RSASSA-PSS with SHA-384 and a 4096-bit key for both message and mask generation. The original device manufacturer (ODM) generates its own key pair to sign the first BIOS segment. AMD signs the ODM's public key with its root signing private key. Both private keys are held in hardware security modules, so a compromise of either key alone cannot corrupt the system.
Key Hierarchy and CSR Fields
Once the public key infrastructure is in place, a BIOS signing key pair is created with a certificate signing request (CSR). The CSR contains standard fields like countryName, stateOrProvinceName, localityName, and organizationName. It also carries a serialNumber—a 32-bit integer in ASCII HEX format—that encodes several important values:
PLATFORM_VENDOR_ID: 8-bit value assigned by AMD for each ODMPLATFORM_MODEL_ID: 4-bit value assigned by the ODM for the platformBIOS_KEY_REVISION_ID: 4-bit key revision encoded as a unary counterDISABLE_SECURE_DEBUG: fuse bit to permanently disable the secure debug unlock featureDISABLE_AMD_BIOS_KEY_USE: fuse bit controlling whether an AMD-signed BIOS with vendor ID 0 can boot on a CPU with non-zero vendor IDDISABLE_BIOS_KEY_ANTI_ROLLBACK: fuse bit for the BIOS key anti-rollback feature
Any of the DISABLE fields are optional. AMD processes the CSR and returns the public portion of the BIOS signing key, signed and certified by AMD's root key, as an RSA Public Key Token file (.stkn).
Building a Signed Firmware Image
The image build process follows a specific sequence. First, the ODM submits its public signing key to AMD, which signs it and returns it. The AMD public key and the signed ODM key become part of the final SPI BIOS image. The BIOS source code is then compiled normally, producing the PEI Volume, Driver eXecution Environment (DXE) volume, NVRAM storage, and other components. The PSP directory and BIOS directory tables are built next, pointing to the various firmware entities.
The ODM generates the signed BIOS Root of Trust Measurement (RTM) signature from the BIOS PEI volume concatenated with the BIOS Directory header, using the private portion of its signing key. That signature is written to the SPI location for the signed BIOS RTM code. Finally, the BIOS binaries, PSP directory, BIOS directory, and other firmware files are combined into the complete SPI BIOS image.
Fusing and Validating in the Field
Platform Secure Boot is activated with a PSB-ready firmware image using one-time programmable (OTP) fuses—on-chip non-volatile memory that can only be written once. Enabling PSB happens in two stages. During fusing, the values from the CSR's serialNumber field are written to the fuses. Validation then checks those fused values against the status code registers.
On successful validation, the BIOS RTM signature is verified with the ODM BIOS signing key, the PSB-specific registers MP0_C2P_MSG_37 and MP0_C2P_MSG_38 are updated with status and fuse values, and the x86 cores are released. If validation fails, those same registers capture the error status, and the x86 cores remain locked. There is no way to roll a fused CPU back to an unfused state.
Enabling Boot Control
With a signed firmware image prepared, we set out to enable PSB on several machines running an updated, unsigned AMI UEFI image (version 2.16). Using a mix of firmware update tools, we scripted the process to move the target systems from 2.16 to 2.18C, the signed release:
. $sudo ./UpdateAll.sh
Bin file name is ****.218C
BEGIN
+---------------------------------------------------------------------------+
| AMI Firmware Update Utility v5.11.03.1778 |
| Copyright (C)2018 American Megatrends Inc. |
| All Rights Reserved. |
+---------------------------------------------------------------------------+
Reading flash ............... done
FFS checksums ......... ok
Check RomLayout ........ ok.
Erasing Boot Block .......... done
Updating Boot Block ......... done
Verifying Boot Block ........ done
Erasing Main Block .......... done
Updating Main Block ......... done
Verifying Main Block ........ done
Erasing NVRAM Block ......... done
Updating NVRAM Block ........ done
Verifying NVRAM Block ....... done
Erasing NCB Block ........... done
Updating NCB Block .......... done
Verifying NCB Block ......... done
Process completed.After the update finished, we rebooted each host:
We then confirmed the correct image was in place by checking the sysfs data exposed through dmidecode:
Verifying Enforcement
The real test was simple: install an unauthorized firmware image and see if the platform refuses to run it. We downgraded a test machine back to the unsigned 2.16 image. With PSB active, the x86 cores should remain locked, halting the boot process. After the downgrade and a reboot, the system showed no signs of life:
This machine wasn’t powered off; it simply failed to boot with an unsigned image:
Because the same BMC-based flashing utility could write the signed image back, the machine was never bricked. The test was a clear success.
Making Signed Images Obvious
Standard firmware image names are alphanumeric (e.g., v2.16A versus v2.18C), so you can’t tell at a glance whether an image carries a signature. Remote attestation that probes PSB status registers or captures them via TPM quote isn’t in place yet. To keep things straightforward, we adopted a strict -sig suffix for all signed images, which can be queried in userspace—for example, by Prometheus. Getting the suffix into the operating system’s view required changes beyond the file name:
- Rename the firmware image file
- Update the version string shown in the setup menu
- Change the POST message
- Adjust the SMBIOS type 0 BIOS version string
All signed releases now carry the -sig tag:
~$ sudo dmidecode -t0
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
# SMBIOS implementations newer than version 3.2.0 are not
# fully supported by this version of dmidecode.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: V2.20-sig
Release Date: 09/29/2020
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 16 MBWhy Hardware Trust Matters
Firmware is an attractive target. Physical attacks on the code that initializes hardware during boot can undermine secure boot mechanisms many consider standard. A hardware root of trust that signs the critical boot path gives you a first line of defense: the platform’s integrity can be verified cryptographically from the very start.
Looking Ahead
This work applies to our current AMD-based platforms. With vendors like AMD and Ampere (ARM), we have the opportunity to push for platform security features to be enabled by default in future hardware generations—details we’ll cover in a follow-up post.
