GPU VulnDB

Database/Control plane, storage & DevOps

AMD EPYC / Ryzen - Hardware Validated Boot enforcement: MULTI-TENANT ISOLATION: Hardware Validated Boot is not properly

CVE-2018-8930Control plane, storage & DevOpsMASTERKEY-1MASTERKEY-2MASTERKEY-3curated

Impact

MULTI-TENANT ISOLATION: Hardware Validated Boot is not properly enforced, so an attacker who can reflash the BIOS can install firmware the platform will accept and execute despite it not being legitimately signed. That is a persistent, below-the-OS implant on a server: it survives reimaging, disk replacement and tenant handoff, and nothing running in the OS can see it. On a bare-metal GPU cloud where nodes are recycled between customers, this is the classic 'previous tenant left something behind' scenario.

Who can reach it

Local with BIOS reflash capability - so root plus SPI write access, a compromised BMC, or physical/supply-chain access. Not remote.

What to do

Fixed in AMD reference firmware (AGESA / PSP / SEV firmware) and delivered only as an OEM SBIOS/BIOS package - Dell, HPE, Supermicro, Lenovo and the ODMs each rebuild and requalify AMD's AGESA drop before shipping. **Expect one to six months of OEM lag**, and on end-of-support platforms expect nothing. Applying it is a drain plus full power cycle, not a driver reload. Verify by reading back the PSP/SMU firmware version afterwards rather than trusting the BIOS version string. The durable control on a bare-metal fleet is not the patch but the process: measure firmware between tenants, enable platform SPI write protection, and treat any node whose firmware measurement changed as suspect rather than reprovisioning it blindly.

References

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.