The article from Unmitigated Risk asks a question that sounds like it should have a straightforward answer: can you verify what software ran on your server from the moment it powered on? The answer is considerably more complicated than checking your Secure Boot logs, and understanding why reveals a structural gap in how server trust is established at the hardware level.
What Secure Boot actually verifies
Secure Boot, as implemented by UEFI firmware on x86 servers, verifies that the bootloader and OS kernel are signed by a key in the firmware’s trusted key database. The key hierarchy has three layers. The Platform Key (PK) is the root trust anchor, typically enrolled by the OEM at manufacture. Key Exchange Keys (KEK) sit below the PK and authorize updates to the signature databases. The signature database (db) and revocation database (dbx) contain the certificates and hashes of allowed and blocked binaries.
When UEFI hands control to the bootloader, it checks the EFI binary’s signature against db and confirms it has not been revoked by dbx. If the check fails, boot halts.
This covers one specific transition point. The UEFI firmware image itself, stored in SPI flash on the motherboard, is not verified by Secure Boot. Secure Boot begins its verification after UEFI is already loaded and executing. If someone modifies the firmware in SPI flash, whether through a vulnerable firmware update channel, a compromised management controller, or physical access to the board, Secure Boot will still report success at its own layer. It signs the output of firmware execution, not the firmware itself.
The management controller blind spot
Every server motherboard includes a Baseboard Management Controller: a small embedded system, typically an ARM Cortex-A core running a stripped Linux or lightweight RTOS, that handles out-of-band access, power control, sensor monitoring, and remote KVM. The BMC runs independently of the host CPU and has direct access to the SPI flash that stores UEFI firmware.
The consequence is that a compromised BMC can reflash UEFI firmware between host boots, entirely outside any measurement the host CPU makes. When the host powers on next, the TPM will faithfully extend PCR[0] with whatever is in SPI flash. If the attacker controls what is in SPI flash, they control PCR[0]. The measured boot record will look consistent; it just measures something the operator did not intend to run.
AMI MegaRAC, which underlies BMC firmware from a substantial fraction of server OEMs, has a documented history of critical vulnerabilities. CVE-2022-40259 and CVE-2022-40258, discovered by Eclypsium, are remote code execution flaws in the Redfish API reachable without authentication in some configurations. CVE-2023-34329 allows authentication bypass via HTTP header manipulation. A BMC with any of these vulnerabilities exposed on an IPMI or management network is a potential firmware write path that bypasses all host-side attestation entirely.
The TPM event log and what it shows
TPM 2.0 measured boot works by extending Platform Configuration Registers with SHA-256 hashes of each boot component. Firmware extends PCR[0] through PCR[7] with measurements of firmware code, option ROMs, Secure Boot state, and bootloader configuration. From PCR[8] onward, the bootloader (typically GRUB via shim) extends with kernel and initrd measurements. Each extension is irreversible: PCR_new = SHA256(PCR_old || measurement). The registers cannot be reset without rebooting through a full TPM reset.
The TPM also produces an event log, a structured record in memory that documents each extension in sequence. With tpm2-tools, you can inspect the current state:
tpm2_pcrread sha256
tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurementsThe event log lets you replay each PCR’s history and verify that the final values are consistent with the recorded measurements. If PCR[0] holds a particular hash, you can confirm it was constructed from a specific sequence of firmware component hashes.
What you cannot do from the event log alone is determine whether those measurements correspond to known-good firmware. For that you need reference values: golden hashes of firmware images that you trust. Getting those reference values requires extracting them from a verified clean system, obtaining them from the OEM, or using a framework like Keylime that maintains a registrar and policy engine comparing TPM quotes against expected states. The reference value problem has no universal solution. There is no registry of firmware hashes that covers the breadth of server hardware variants in production.
PKfail and the key management reality
In 2024, researchers discovered that a test Platform Key from AMI’s UEFI reference firmware code, labeled in the source as a key not to trust, had shipped in production firmware from at least 22 device manufacturers, including Supermicro systems. This is CVE-2024-8105. The PK is the root of the Secure Boot hierarchy: whoever holds the private half of the PK can update the KEK and db databases, and therefore sign arbitrary bootloaders that Secure Boot will accept on any affected device.
This is the practical state of Secure Boot key management on production servers. The Platform Key is set at manufacture by OEMs who frequently base their firmware on reference code with reference keys, and those keys are rarely rotated across the fleet. Operators running standard server hardware accept whatever trust root the OEM embedded at the factory.
UEFI does provide a path to enroll your own PK (SetupMode allows replacing the key hierarchy), but doing so in production requires firmware key management infrastructure that most operators do not maintain. The result is that Secure Boot’s trust root is frequently a key controlled by an OEM, derived from reference code, and potentially shared across a broad hardware population.
The execution surface before verification
LogoFAIL, disclosed in late 2023 by Binarly, identified a class of vulnerabilities in UEFI image parsers: the code inside UEFI that processes BMP, JPEG, and GIF images for rendering boot logos. These parsers run during UEFI initialization, before Secure Boot signature checking begins. An attacker who can replace a logo image in the EFI System Partition can execute arbitrary code in the UEFI context without triggering any Secure Boot failure, because the exploit fires before the verification machinery is operational.
The attack surface is the UEFI firmware codebase itself. The EDK2 base, which underlies most modern UEFI implementations, covers millions of lines of C. OEMs add their own drivers, option ROM handlers, and customization layers on top. Image parsers, network stack implementations, and driver dispatch code all execute in the pre-verification window. CHIPSEC, Intel’s open-source firmware security analysis framework, can audit SPI flash write protections, Intel Boot Guard configuration, SMM lock bits, and Secure Boot variable state. Auditing configuration is not the same as attestation. CHIPSEC does not produce a signed statement a remote verifier can check.
Where the standards work stands
IETF RFC 9334, published January 2023, defines the RATS (Remote ATtestation procedureS) architecture. It separates three roles: the Attester producing evidence, the Verifier evaluating that evidence against reference values, and the Relying Party making a trust decision based on the attestation result. The clean separation enables third-party attestation services, so the relying party does not need to directly trust the attester’s infrastructure.
DICE (Device Identifier Composition Engine), developed by the Trusted Computing Group and used in Microsoft Pluton and Azure Sphere, addresses the layer beneath the host CPU’s TPM. Each firmware layer measures the next and derives a new key pair whose private key is bound to those measurements. A DICE chain produces attestation evidence rooted in CPU-level identity rather than in the UEFI layer or the TPM configuration alone.
AMD SEV-SNP provides hardware-rooted attestation for virtual machines, where the guest firmware measurement is included in an attestation report signed by a key derived from the CPU package’s hardware identity (the Versioned Chip Endorsement Key, VCEK), with AMD’s Key Distribution Service as the trust anchor. Intel TDX does the equivalent using ECDSA-based quotes verified through Intel’s Provisioning Certification Service. Both are confidential computing technologies primarily aimed at tenant isolation from cloud providers. They provide a real hardware root, but only for the guest-visible stack. Host firmware, the BMC, and the physical layer beneath remain outside what any cloud tenant can verify.
Keylime, a CNCF project with strong Red Hat involvement, is the most practical production deployment path for TPM-based remote attestation on Linux. It runs an agent on each node, a central verifier that compares TPM quotes against policy, and a registrar that maintains enrollment state. It also integrates with IMA (Integrity Measurement Architecture), the Linux kernel subsystem that extends PCR[10] with hashes of every file executed or memory-mapped at runtime, extending measurement from boot into the running system. Linux IMA with ima-evm-utils for file signing gives you runtime file integrity alongside boot integrity, though the overhead is non-trivial and deployment in cloud environments is rare.
The realistic picture
For bare-metal servers, verification means: the OS kernel was signed (Secure Boot), the TPM recorded what the firmware claims it measured (event log and PCR values), and you can compare those measurements against expected values if you have reference values and a framework to check them. You cannot verify what the BMC executed before UEFI started. You cannot verify the UEFI firmware image itself without Intel Boot Guard or an AMD equivalent correctly configured at manufacture, which is OEM-dependent and far from universal deployment.
For cloud workloads on standard VMs, the virtual TPM reflects the guest’s boot measurements, but the vTPM does not chain to physical hardware. Azure Trusted Launch and GCP Shielded VMs provide measured boot for guests with the attestation root sitting in the cloud provider’s infrastructure, not in the physical silicon.
Confidential computing (SEV-SNP, TDX) is the current best available answer for remote parties who need hardware-rooted proof of what is running. Its tooling is still maturing, its deployment is not universal, and the reference value problem persists: knowing what hash the firmware produced only matters if you have a reliable source for what hash trustworthy firmware should produce.
The gap between a clean kernel boot and a cryptographic proof to a remote verifier of what ran on that machine from power-on is wider than most operational security tooling acknowledges. RATS, DICE, and confidential computing are filling parts of that gap, but the server ecosystem’s hardware diversity, OEM key management practices, and the BMC’s out-of-band access mean that end-to-end attestation is a harder problem than the presence of a Secure Boot checkbox implies.