Researchers discover potentially catastrophic exploit present in AMD chips

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.