AMD Secure Processor bootloader - SPIROM upgrade path: MULTI-TENANT ISOLATION: An attacker who can drive the SPIROM

Impact

MULTI-TENANT ISOLATION: An attacker who can drive the SPIROM upgrade path can pass unsanitised parameters to the ASP bootloader and overwrite memory, reaching arbitrary code execution in the secure processor. This is the classic firmware-update-as-attack-surface problem: the mechanism you use to patch the platform is itself the way in.

Who can reach it

Local, requires access to the SPI ROM upgrade mechanism - typically root plus flash write, or a compromised BMC that can drive host SPI.

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. Worth pairing with BMC hardening: on most server designs the BMC can write host SPI, so a BMC compromise reaches this directly. Restrict who can invoke firmware updates and require signed update packages end to end.

References