Researchers discover potentially catastrophic exploit present in AMD chips
Researchers have revealed a long‑standing vulnerability in AMD CPUs that allows attackers with kernel‑level (ring 0) access to escalate into system management mode and potentially install persistent firmware‑level malware that survives OS reinstalls. Commenters debate how serious this is in practice—given the high privileges required and the likely persistence in motherboard firmware rather than the CPU itself—while noting particular concern for cloud and high‑security environments. AMD’s decision not to patch certain still‑popular Ryzen 3000 desktop chips sparks criticism about support lifetimes and broader questions about opaque firmware, hardware trust, and owner control over their devices.
Exploit characteristics
- Vulnerability is in AMD CPUs’ handling of a model-specific register (MSR); with ring 0 (kernel) access, SMM configuration can be modified even when the SMI lock is set.
- This enables arbitrary code execution in System Management Mode (SMM), effectively ring −2, below the OS and hypervisor.
- Discussion stresses: you must already have ring 0 code execution, but this bug turns a kernel compromise into a stable firmware‑level foothold.
Persistence and what actually breaks
- Multiple commenters clarify that the CPU itself has no writable, persistent storage for attacker code (microcode is ROM + signed updates).
- Persistence is expected via motherboard firmware (BIOS/UEFI/flash), or bootloaders, not the CPU die.
- Some articles state you may have to “throw away the computer”; commenters push back that in practice you’d replace or reflash the motherboard/BIOS, not the CPU.
- Recovery options like dual BIOS or external flash programming are discussed; feasibility depends on whether compromised firmware allows reflashing. Overall remediation complexity is considered high.
How severe is it?
- One camp: “catastrophic” because it bypasses Platform Secure Boot protections, can hide from the OS and AV, and can survive OS reinstalls.
- Other camp: impact is limited because ring 0 is already game‑over on typical desktops; this mostly matters where ring 0 shouldn’t imply firmware control.
- General consensus: technically serious, but real‑world risk depends heavily on threat model and prerequisites.
AMD’s response and Ryzen 3000 controversy
- AMD plans firmware fixes for most affected products (especially datacenter), but lists Ryzen 3000 (“Matisse”) desktop CPUs as “no fix planned.”
- Intense disagreement over whether ~5‑year‑old desktop CPUs are “old” enough to drop security support.
- Some argue there are still large installed bases and that not fixing them is reputationally damaging and consumer‑hostile; others say age, low margin, and ring‑0 prerequisite make the risk acceptable.
- EU/EEA consumer‑protection time limits (2–5 years) are mentioned; some think this could justify demanding remedies.
Cloud / virtualization angle
- Concern: could guests escape into host/firmware?
- Counterpoints: typical VMs lack direct MSR access, and major providers likely patched quickly; impact is “unclear” but seen as more relevant than desktops if it exists.
- In SEV/PSP models, this is framed as a foundational breach of the intended separation between owner‑controlled guests and vendor‑controlled root of trust.
Broader trust and policy themes
- SMM, PSP/ME, and hidden firmware are criticized as inherently dangerous attack surfaces that undermine device owners.
- Others view the exploit as a potential way to disable or work around vendor‑controlled “trojans,” enabling more user control (e.g., coreboot‑style goals).
- Some call for laws mandating open firmware source, open documentation, and owner‑controlled flashing, with changeable cryptographic keys.