AMD Secure Processor (Ryzen / Ryzen Pro / Ryzen Mobile): MULTI-TENANT ISOLATION: Insufficient access control

Impact

MULTI-TENANT ISOLATION: Insufficient access control on the Secure Processor lets code already running with OS administrator rights reach into the AMD Secure Processor and execute there. The ASP sits below the hypervisor and below Secure Boot, so once an attacker is inside it, everything the platform's security rests on - memory encryption keys, fTPM state, boot measurements - is theirs. On a shared host this is the end of any isolation guarantee you were making to tenants, and the compromise survives an OS reinstall.

Who can reach it

Local, requires OS administrator/root plus the ability to flash or load a signed driver. Not remotely reachable. Realistically this is a post-exploitation depth charge: an attacker who already owns the host uses it to get persistence you cannot wash out.

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. AMD's fix was a PSP firmware update carried in AGESA. Note this batch (the CTS-Labs disclosures) targeted client Ryzen silicon rather than EPYC; verify against your actual server SKU before spending a maintenance window on it.

References