Armed to Boot: an enhancement to Arm's Secure Boot chain

Closing the UEFI firmware gap on Arm servers

UEFI-based secure boot protects the bootloader from tampering, but the UEFI firmware itself sits outside that trust boundary. Malware that implants itself in SPI flash can survive OS reinstalls and drive replacements because it loads before the OS does. Attacks of this kind have grown more common, pushing platform vendors to sign UEFI firmware as a mitigation. On x86 systems that process is well established, but Arm servers historically lacked an equivalent mechanism. That gap required a close look at how Arm’s secure boot architecture actually works.

How Arm trusted firmware authenticates boot stages

Arm’s Trusted Board Boot Requirements (TBBR) define a chain of cryptographically signed binary images, each responsible for a distinct phase of system initialization. The bootloader stages are:

• BL1 — Determines cold vs. warm boot, sets up exception vectors, CPU control registers, and platform-level features like watchdog, MMU, and DDR initialization.
• BL2 — Prepares Arm Trusted Firmware (ATF), initializes the console, maps memory for the MMU, and sets message buffers for the next bootloader.
• BL3 — Initializes runtime services for system topology detection, then hands off from the ATF “secure world” to the “normal world” UEFI firmware. Context is isolated so secure state information does not leak into normal world execution.

Each image is authenticated by a public key stored in a signed certificate, traceable back to a root key held in SoC one-time programmable (OTP) memory or ROM.

TBBR was originally designed for cell phones, establishing a reference chain of trust from first ROM execution (BL1) through handoff to normal world firmware (BL3). For server deployments, that model has limitations:

1. SoC manufacturers dominate the secure boot chain, leaving customers with little involvement.
2. Each customer requires a unique SoC SKU, which does not scale for manufacturers managing thousands of SKUs.
3. The SoC manufacturer handles end-to-end signing and PKI maintenance, adding complexity such as USB key fobs for signing.
4. The model does not scale beyond the manufacturer.

What worked for phones does not translate to scale-out server infrastructure, which is why a different approach was needed for Arm-based systems.

Ampere’s secure boot implementation

Ampere’s Altra Max server CPU implements a signed boot process derived from the ATF model but with notable differences. The boot sequence relies on System Control Processors (SCP): the System Management Processor (SMpro) handles secure boot and BMC communication while the Power Management Processor (PMpro) manages power features like Dynamic Frequency Scaling and on-die thermal monitoring.

At power-on-reset, the SCP runs a system management bootloader from ROM and loads SMpro firmware. After initialization, the SMpro starts the PMpro power management stack and ATF threads. ATF BL2 and BL31 bring up DRAM and PCIe, after which control passes to the BL33 BIOS.

Authentication flow

The SMpro firmware reads Ampere’s public key (ROTPK) from the SMpro key certificate in SCP EEPROM, computes a hash, and compares it to the hash stored in eFuse. Once authenticated, that public key decrypts key and content certificates for SMpro, PMpro, and ATF firmware. Each stage cascades: the SMpro public key authenticates SMpro/PMpro images and ATF keys, which in turn authenticate ATF images. The root of this chain is Ampere’s eFuse, an OTP memory region that can be written only once and is read-only thereafter.

That hardware root of trust signs only system and secure world firmware. Given the large OTP region available in the SoC and prior experience with AMD Platform Secure Boot, the natural question was whether a customer-controlled key hash could also be inserted into that eFuse domain.

Single Domain Secure Boot

Single Domain Secure Boot (SDSB) extends the authentication flow by adding a hash of the customer public key — in this case Cloudflare’s firmware signing key — to the eFuse domain. This allows UEFI firmware to be verified by a hardware root of trust. The verification happens in already-validated ATF firmware at the BL2 stage. A public key (dbb) is read from UEFI secure variable storage, hashed, and compared to the hash in eFuse. If they match, that key decrypts the BL33 content certificate and validates the BIOS and remaining boot items. SDSB thus validates the entire software boot chain with a single eFuse root of trust.

Implementation steps

SDSB requires coordination between the SoC vendor, the original device manufacturer (ODM), and the customer:

Cloudflare first generates a public-private key pair through its internal PKI. The public key is provided to the ODM as dbb.auth and dbu.auth in UEFI secure variable format. Ampere supplies a Software Release Package (SRP) containing BMC, SCP, UEFI, and CPLD firmware to the ODM, which customizes it for the platform. The ODM generates a board file for the hardware configuration and modifies UEFI to enroll dbb and dbu into secure variable storage on first boot.

A UEFI.slim file is then produced from the ODM’s UEFI ROM image, ATF, and board file. Unlike AMD PSB — which signs only the first block of boot code — the entire SLIM image and ATF files are signed with Cloudflare’s private key, embedding a signature hash that only the correct public key can authenticate. The ODM packages the result into .HPM format compatible with the platform BMC.

In parallel, the debug fuse selection and a hash of the DER-formatted public key are provided to Ampere. Ampere creates a one-time-run Security Provisioning (SECPROV) .slim firmware that programs the debug fuse settings and public key hash into the SoC eFuses. The ODM packages this into a .hpm file for BMC firmware update tooling.

Key provisioning during manufacturing

During system manufacturing, firmware is pre-programmed into storage ICs before motherboard placement. The SCP EEPROM contains the SECPROV image rather than standard SCP firmware. On first power-on, an IPMI command releases the Ampere processor from reset so SECPROV can run and burn the eFuse with the public key hash and debug fuse settings.

Once provisioning is complete, the SCP EEPROM is reprogrammed with its normal firmware. On the next power-on, ATF detects that no keys exist in secure variable storage and allows UEFI to boot regardless of signature. The first UEFI boot enrolls the public key into secure variable storage and reboots. ATF is validated against Ampere’s public key hash as usual; the dbb public key is then checked against the eFuse hash, and UEFI boots only if both verifications succeed.

Validating the chain

Validation first confirms that the eFuses were properly destroyed during programming, which imprints the public key hash into an immutable memory region. An IPMI OEM command to the BMC surfaces a signal from SECPROV firmware indicating programming completion.

Next, corruption tests confirm that the boot chain is enforced. Tampering with SCP, ATF, or UEFI firmware should block boot authentication and prevent the machine from reaching the OS. With firmware intact, happy-path validation proceeds through the boot order: BMC, SCP, ATF, and UEFI, each observable via serial console. UEFI automatically enrolls dbb and dbu files to secure variable storage and triggers a system reset.

If the machine boots to the OS after the reset, the feature is working. Further verification extracts the dbb file via the UEFI shell and compares its hash against the one sent to Ampere. A deliberately unsigned UEFI image should cause authentication failure at the BL3-2 bootloader stage, sending ATF into a boot loop — the same result expected from a UEFI image signed with incorrect keys.

Authenticating every subsequent boot

On all later boot cycles, ATF reads the dbb secure variable, hashes it, and compares it to the read-only public key hash in eFuse. A match means the key variable can be trusted, and that key is then used to authenticate the signed UEFI firmware before the system proceeds to the OS. This closes the gap that previously left UEFI firmware itself unprotected on Arm servers, bringing the same hardware-rooted trust to the full boot chain that was previously reserved for firmware below UEFI.

What a Failed Boot Actually Looks Like

Since the test platform has the root of trust eFuse set at build time, we couldn't demonstrate the initial provisioning flow on a clean machine. In a production set-up, that flow would begin with a custom BMC command that instructs the SCP to burn the ROTPK into the SoC's OTP fuses, followed by feedback to the BMC confirming whether the write succeeded. On the first boot of the UEFI image, the firmware would then write the dbb and dbu into secure storage.

What we can show is the transition between an unsigned and a signed BIOS. Flashing the unsigned image results in a machine that simply fails to boot.

Beneath that silent failure, the boot process still gets underway. The System Control Processor (SCP) is the first component to run, and its boot flow breaks down as follows:

1. The SCP image carries a key certificate containing Ampere's generated ROTPK and the SCP key hash. The SCP calculates the ROTPK hash and compares it against the OTP fuses. A mismatch stops the boot right there. On a match, the SCP proceeds to verify and boot the PMpro and SMpro firmware, which then enter the ATF authentication flow.
2. Once SCP authentication completes, the BL1 key is handed to the first-stage bootloader via the SCP hand-off block (HOB), kicking off the standard three-stage ATF bootloader authentication described earlier.
3. At BL2, the firmware reads dbb from secure variable storage, uses it to authenticate the BL33 certificate, and finishes by launching the BL33 UEFI image.

Extending the Chain Beyond UEFI

The server management interface—the BMC—has become a prime target for ransomware, implants, and disruptive operations. With both local and remote attack vectors, the BMC can be compromised over the network, and malware there can persist on the host. Tools like flashrom or socflash can rewrite BMC flash directly, without the firmware resilience that the UEFI boot chain now enforces.

The next step is to establish a cryptographically secure host before boot time, using infrastructure that doesn't depend on the host CPU. The modular approach under consideration follows the Open Compute Project's Data Center Secure Control Module (DC-SCM) 2.0 specification. That direction would let Ampere standardize the root of trust, sign the BMC firmware, and use physically unclonable function (PUF) based identity keys for components and peripherals. Replacing OTP fusing with PUF keys also solves a practical problem: OTP fuses tie a permanent identity to a machine, making it impossible to truly wipe and reuse, or "e-cycle," hardware.