AMD Secure Processor (ASP) bootloader - image header parsing: MULTI-TENANT ISOLATION: The ASP bootloader reads and acts

Impact

MULTI-TENANT ISOLATION: The ASP bootloader reads and acts on fields from a firmware image header *before* it verifies that image's signature. Attacker-controlled values therefore reach range checks and pointer arithmetic in the pre-verification window, giving code execution in the secure processor's own bootloader. This is upstream of every signature check on the platform: an attacker who lands here owns the root of trust and can persist beneath any OS reinstall or disk wipe.

Who can reach it

Local. Requires the ability to place a crafted image where the ASP bootloader will parse it - in practice SPI ROM write access or a compromised firmware update path, so root plus flash access, or a supply-chain/refurbishment scenario.

What to do

Fixed in AMD reference firmware (AGESA / SEV firmware) and delivered to you only as an OEM SBIOS/BIOS package - Dell, HPE, Supermicro, Lenovo, Gigabyte and the ODMs each rebuild and requalify AMD's AGESA drop before it ships. **Expect months, not weeks**: AMD publishes the bulletin, the OEM ships BIOS somewhere between one and six months later, and for platforms past their support window it may never arrive at all. Applying it is a full node power cycle with the host drained - not a driver reload, not a live patch. Track it as a firmware campaign per server SKU, not per kernel version, and verify afterwards by reading back the SMU/PSP firmware version rather than trusting the BIOS revision string. Because this is bootloader code inside the ASP, there is no software workaround and no kernel-side mitigation - you either get the OEM BIOS or you do not. In the meantime, the compensating control is guarding SPI write access: enable the platform's SPI ROM protection and BIOS write-protect, and treat any node that has been through third-party hands as untrusted.

References