HN Debrief

AMD silently removes memory encryption from consumer Ryzen CPUs

  • Security
  • Hardware
  • Infrastructure
  • Regulation

The report says AMD removed support for transparent system memory encryption from consumer Ryzen CPUs through newer AGESA firmware, while keeping it on Ryzen Pro models. This is not the per-VM encryption used in datacenter parts. It is SME or TSME, a machine-wide memory encryption feature that writes DRAM contents in encrypted form with keys managed by the memory controller. That matters most for cold boot and bus snooping style attacks against a running machine, but several people pointed out it also raises the cost of Rowhammer-style bit-flip attacks because attackers lose direct control over physical bit patterns. A few comments said the feature had been unstable on some systems, especially around VFIO and some GPU drivers, which made people suspect AMD may have been removing something it never fully qualified on consumer boards. Others found older AMD bootloader release notes suggesting Pro-only support had long been the intended policy and consumer availability may have been an accidental or at least unofficial exposure.

If you rely on undocumented firmware features, treat BIOS and AGESA updates like risky product changes, not routine maintenance. More broadly, buyers should push vendors to publish stable capability matrices because silent SKU segmentation now reaches down into firmware, not just hardware specs.

Discussion mood

Strongly negative. Most people were less alarmed by the specific loss of memory encryption than by AMD silently removing an already-shipping capability through firmware, refusing to explain why, and using firmware to sharpen market segmentation after the sale.

Key insights

  1. 01

    Memory encryption helps beyond cold boot

    The useful security case is broader than 'someone freezes your RAM'. Because SME encrypts DRAM with a hardware-managed key, attackers cannot easily map chosen plaintext to chosen physical bits. That makes Rowhammer and similar bit-flip attacks harder to target, and it also blunts some memory bus and side-channel exposure. It is not full integrity protection, but it is a real defense layer that changes the attack surface for a running machine.

    Do not classify memory encryption as only a spy movie physical access feature. If you run systems that hold sensitive data in RAM, include DRAM encryption in your platform security checklist alongside full-disk encryption and ECC.

      Attribution:
    • simcop2387 #1
    • westurner #1
    • Integer #1
    • bonzini #1
    • crest #1
  2. 02

    This was likely never meant for consumer Ryzen

    Older AMD release notes and product segmentation details point to a cleaner story than the headline implies. SME appears to have been intended as a Pro-only feature for these client parts, while SEV remained the datacenter feature set. That makes the change look less like a late architectural retreat and more like AMD finally enforcing a support boundary that had been porous in practice.

    Separate 'present in silicon' from 'supported in this SKU' when evaluating platform features. For purchasing and deployment, rely on vendor support matrices and long-lived documentation, not just BIOS menus or what happened to work on early firmware.

      Attribution:
    • eigenform #1
    • porridgeraisin #1
  3. 03

    Some users saw real stability problems

    Several people who tried to use the feature in anger said it was flaky, especially with VFIO, QEMU, NVIDIA drivers, and amdgpu initialization. That does not prove AMD removed it for technical reasons, but it does make 'this was never properly validated on consumer platforms' a credible explanation. If so, AMD chose the worst possible version of that decision by disabling it without a clear advisory.

    If you are using niche firmware security features on commodity platforms, validate them under your exact virtualization and driver stack. A BIOS toggle is not evidence that a feature is production-ready.

      Attribution:
    • pshirshov #1 #2
    • endgame #1
    • hugmynutus #1
  4. 04

    The backlash is really about post-sale downgrades

    People treated this like the SSD bait-and-switch problem, not a narrow security dispute. The objection is that a physical product lost a capability after purchase through a firmware update, even if that capability was lightly documented or unofficial. For operators, that breaks the old assumption that firmware updates merely fix bugs and add support. They now also rewrite the value proposition of hardware you already bought.

    Add firmware governance to procurement and fleet management. Track feature regressions in release testing, and avoid automatic BIOS rollouts on systems where a hidden capability matters to your business.

      Attribution:
    • kubik369 #1
    • cwillu #1
    • close04 #1
    • cogman10 #1
    • mort96 #1

Against the grain

  1. 01

    Most consumers were never the threat target

    The narrow security value for a typical home PC is easy to overstate. Full-disk encryption already protects data at rest, and exploiting live RAM usually requires physical access plus expensive or specialized techniques like cold boot capture or bus interception. For most buyers, this was not a meaningful purchase criterion, which is why some people saw the outrage as disproportionate to the practical risk.

    Keep your threat model honest before turning a niche hardware defense into a broad purchasing requirement. For many endpoints, effort is better spent on patching, credential hygiene, and disk encryption than on chasing undocumented firmware security toggles.

      Attribution:
    • thg #1
    • porridgeraisin #1
    • riobard #1
    • shanoaice #1
  2. 02

    A broken unsupported feature is not a promise

    A few commenters argued AMD's real failure was communication, not the removal itself. If the feature was unstable, unofficial, and never marketed on consumer Ryzen, disabling it can be reasonable. The stronger criticism is that AMD left users to guess whether this was segmentation, bug mitigation, or a serious hidden flaw.

    Treat unofficial hardware capabilities as revocable until the vendor clearly commits to them. If your use case depends on one, require an explicit support statement before standardizing on that platform.

      Attribution:
    • ChocolateGod #1
    • vinay427 #1

In plain english

AGESA ↩
AMD Generic Encapsulated System Architecture, the AMD firmware code used by motherboard BIOS and UEFI to initialize Ryzen and other AMD processors.
BIOS ↩
Basic Input/Output System, commonly used to refer to motherboard firmware settings and update packages, even on modern UEFI systems.
DRAM ↩
Dynamic Random-Access Memory, the main volatile memory used by a computer while it is running.
QEMU ↩
An open source machine emulator and virtualizer used to run other operating systems in software.
Rowhammer ↩
A hardware attack that repeatedly accesses DRAM rows to induce bit flips in nearby memory cells.
SEV ↩
Secure Encrypted Virtualization, an AMD server feature that gives different virtual machines separate memory encryption protections.
SME ↩
Secure Memory Encryption, an AMD feature that encrypts system memory with a hardware-managed key so DRAM contents are not stored in plain text.
TSME ↩
Transparent Secure Memory Encryption, the motherboard or firmware-facing form of AMD memory encryption that applies system-wide without software changes.
VFIO ↩
Virtual Function I/O, a Linux framework used to pass hardware devices directly through to virtual machines.

Reference links

Primary reporting and issue tracking

AMD documentation and performance references

Security background

  • Wikipedia on cold boot attacks
    Background on the physical attack memory encryption helps mitigate
  • TEE.fail
    Referenced as an example of attacks involving memory bus snooping or trusted execution weaknesses

Legal and policy references