PSB Unfused: Why Consumer Boards Accept Any Firmware

AMD Platform Secure Boot (PSB) is a hardware fuse. When fused, the CPU validates the firmware signature on every boot -- if the signature doesn't match a key burned into the processor, the machine refuses to POST. Consumer gaming boards almost never fuse it. My Ryzen 7 5800XT boots whatever I put on the SPI flash chip. This is why SmmInfect works.

I spent a day researching PSB before I started the SmmInfect project. If my CPU had PSB fused, the entire approach -- flashing a modified BIOS with my SMM module -- would be dead on arrival. I needed to confirm, not assume, that my hardware would accept unsigned firmware.

What PSB actually is

PSB is part of AMD's silicon security. Inside every AMD CPU is the Platform Security Processor (PSP) -- an ARM Cortex-A5 core that runs before the x86 cores wake up. On every boot, the PSP validates the firmware image on the SPI flash. If PSB is fused, the PSP checks the firmware's RSA signature against a public key hash stored in one-time-programmable (OTP) fuses on the CPU die.

// PSB boot flow (simplified)
//
// 1. power on
// 2. PSP ROM boots (ARM Cortex-A5, not x86)
// 3. PSP loads its own firmware from SPI flash
// 4. PSP checks PSB fuse state:
//
//    fused = YES:
PSP reads OTP key hash
PSP verifies BIOS signature against OTP hash
//       signature valid?   -> boot continues
//       signature invalid? -> machine halts (no POST)
//
//    fused = NO (my hardware):
PSP skips firmware signature check
//       any firmware on SPI flash boots fine
//       modified BIOS? no problem. Q-Flash accepts it.

The fuses are one-time-programmable. Once blown, they can't be undone. The public key hash is permanently etched into the silicon. This is why OEM machines with PSB fused can't have their BIOS modified -- the CPU itself rejects any firmware that isn't signed by the OEM's key.

Checking my CPU's PSB status

I verified PSB status by reading MSR 0xC00110A2 -- the PSB status register. On AMD Zen 2+ processors, this MSR reports whether PSB is fused and what key hash is burned in.

// reading PSB status from Windows (requires ring 0)
let psb_status = rdmsr(0xC00110A2);

// bit 0: PSB enable (fuse state)
let psb_enabled = (psb_status >> 0) & 1;

// bits 1-2: platform vendor ID
let vendor_id = (psb_status >> 1) & 0x3;

// my result:
// psb_status = 0x0000000000000000
// psb_enabled = 0 (NOT fused)
// vendor_id = 0 (no vendor key)
//
// the OTP fuses are all zeros -- no key burned in
// CPU will boot any firmware without signature check

All zeros. The OTP fuses on my Ryzen 7 5800XT have never been programmed. No vendor key, no signature requirement. The PSP runs its boot ROM, loads firmware from SPI flash, and starts the x86 cores -- no questions asked.

Who fuses PSB and who doesn't

The pattern is clear once you look at enough hardware:

// PSB fusing patterns across hardware

// CONSUMER / GAMING (almost never fused)
Gigabyte B550M DS3H:    unfused  (my board)
Gigabyte X570 Aorus:     unfused
ASUS ROG X570-E:         unfused
MSI B650M Mortar:        unfused
ASRock B550 Steel Legend: unfused

// ENTERPRISE / OEM (typically fused)
Dell OptiPlex 7080:     fused  (Dell key)
HP ProDesk 405 G8:       fused  (HP key)
Lenovo ThinkCentre M75q: fused  (Lenovo key)
Dell PowerEdge R7515:    fused  (Dell key)

// SERVER (almost always fused)
AMD EPYC 7003 series:   fused  (varies by OEM)
Supermicro EPYC boards:  fused  (Supermicro key)

Consumer board manufacturers don't fuse PSB because it would prevent customers from updating to third-party BIOS versions, custom firmware, or modded BIOS images. The enthusiast PC market values the ability to modify firmware. Gaming boards, overclocking boards, and DIY boards all ship unfused.

Enterprise OEMs fuse PSB because they control the hardware lifecycle. Dell, HP, and Lenovo burn their own keys during manufacturing. This means only Dell-signed firmware runs on Dell machines. It prevents supply chain attacks, evil maid scenarios, and end-users installing unauthorized firmware. For enterprise security, this is the right call.

What unfused PSB means for SmmInfect

With PSB unfused, the attack surface is wide open. I extract the stock BIOS with UEFITool, insert my DXE_SMM_DRIVER module, rebuild the firmware volume, and flash it with Q-Flash Plus. The PSP loads my modified firmware without complaint. My SMM code executes before the OS boots, in a memory region the OS can't even address.

If PSB were fused on my board, none of this would work. The PSP would check the firmware signature, fail (because I modified the image), and halt the boot. The machine would refuse to POST. I'd be dead at step 1.

The Q-Flash Plus workflow

Because PSB is unfused, my firmware iteration cycle is fast. I keep a stock BIOS image and a modified image on the same USB drive. The workflow looks like this:

// firmware modification workflow

// 1. extract stock BIOS
UEFITool: open stock_bios.bin
// navigate to DXE firmware volume
// right-click -> Insert after -> my_smm_driver.ffs

// 2. rebuild firmware image
UEFITool: save modified_bios.bin

// 3. flash via Q-Flash Plus (board powered off)
//    rename modified_bios.bin to GIGABYTE.bin
//    copy to FAT32 USB drive
//    insert USB in designated Q-Flash Plus port
press Q-Flash Plus button
//    LED blinks for ~90 seconds
//    LED stops -> flash complete

// 4. if anything goes wrong:
//    rename stock_bios.bin to GIGABYTE.bin
//    repeat step 3
//    back to stock in 90 seconds

Q-Flash Plus doesn't need the CPU or RAM installed. It's a microcontroller on the board that directly programs the SPI flash chip. This means even if my modified firmware is so broken that the CPU can't POST, Q-Flash Plus can still recover it. I bricked the board twice during development and recovered both times in under two minutes.

Can PSB be fused after the fact?

In theory, yes. The OTP fuses can be programmed by anyone with the right tools and AMD's PSB fusing utility. In practice, fusing requires access to AMD's Secure Key Provisioning (SKP) toolchain, which is only available to OEM partners under NDA. A random consumer can't fuse their own CPU.

Even if you could fuse it, you'd need to generate an RSA key pair, sign your firmware with the private key, and burn the public key hash into the CPU. If you lose the private key, your CPU becomes a brick -- it will only boot firmware signed with a key you no longer have. There's no recovery. The fuses are permanent.

For my research, unfused PSB is a feature, not a bug. It means I can iterate rapidly -- modify firmware, flash, test, reflash stock if it breaks. If PSB were fused, every firmware modification would require re-signing with my key, and a mistake could brick the CPU permanently. The unfused state is actually what makes this kind of low-level security research practical.