The reporting frames the removal as alarming precisely because it shipped with no CVE, no advisory, and no AGESA changelog entry. Users only discovered the change because dmesg stopped logging the SME-active line at boot, which the article argues undermines the entire premise that hardware security features degrade transparently and with notice.
The editorial argues this inverts the mental model of how hardware security is supposed to degrade, contrasting AMD's silence with Intel's public deprecation of SGX and Apple's documented Secure Enclave changes. The lack of any direct customer communication, SKU change, or spec sheet update is presented as the core practitioner concern.
The article notes that AMD has historically positioned the full SME/SEV stack as an EPYC server feature, and that consumer Ryzen chips had only 'quietly carried' the capability for years. This framing implies the removal may reflect AMD tightening product segmentation rather than addressing a security flaw, since the feature was never officially marketed to consumers.
The editorial emphasizes that SME is a meaningful defense-in-depth layer against cold-boot attacks, bus interposers, and evil-maid scenarios — exactly the threats faced by laptops or machines serviced by untrusted technicians. While not a defense against privileged software attackers, its silent removal degrades a tangible protection that some users had explicitly enabled via mem_encrypt=on.
A Tom's Hardware report, currently sitting at 227 points on Hacker News, documents that AMD has removed Secure Memory Encryption (SME) support from consumer Ryzen CPUs via a recent AGESA microcode/firmware update. Users who previously had `cpuid` reporting SME capability — and who had enabled `mem_encrypt=on` in their kernel command line — are finding the feature simply gone after a motherboard BIOS refresh. No release notes mention it. No security advisory accompanies it. AMD engineers participating in the relevant forum threads have, per the reporting, gone quiet when asked directly what changed and why.
SME is the lighter sibling of SEV: a single AES key, managed by the on-die security processor, transparently encrypts pages of DRAM so that anyone with physical access to the DIMMs — cold-boot attack, bus interposer, evil-maid scenarios — sees ciphertext instead of cleartext secrets. It's not a defense against a privileged software attacker, and it was never marketed as one. It is, however, a meaningful defense-in-depth layer for laptops, kiosks, and workstations that might be physically seized or serviced by an untrusted technician. Consumer Ryzen chips had quietly carried this capability for years, even though AMD has historically positioned the full SME/SEV stack as an EPYC server feature.
The change appears to have shipped without any SKU change, any spec sheet update, or any direct customer communication. Affected users found out because `dmesg` stopped logging the `AMD Secure Memory Encryption (SME) active` line they were used to seeing at boot.
This is the part that should make practitioners uncomfortable. Silently removing a security feature via a firmware update — with no CVE, no advisory, no entry in the AGESA changelog — inverts the entire mental model of how hardware security is supposed to degrade. When Intel deprecated SGX on consumer chips, they at least told people. When Apple changes Secure Enclave behavior, it shows up in release notes that security researchers can audit. A silent removal means that anyone who built a threat model around SME being present — a small group, but it includes journalists, security researchers, and a non-trivial chunk of the Qubes/Tails crowd — has a degraded posture they don't know about.
The second-order problem is worse: it sets a precedent. AGESA updates are not optional in any practical sense. They're how mitigations for actual vulnerabilities (Inception, Zenbleed, the entire speculative-execution menagerie) get delivered. You can't refuse the AGESA update without refusing the next round of microcode fixes for whatever Zen-something side channel drops in Q3. Coupling silent feature removals to mandatory security updates means users have no meaningful choice and no meaningful audit trail.
Community reaction on the thread skews toward two theories, neither flattering. The first is product segmentation: AMD wants memory encryption to be an EPYC/Pro differentiator, and the consumer presence was always an accident of shared silicon they tolerated until they didn't. The second is that something broke — a microarchitectural edge case, a power/perf regression, an interaction with newer DDR5 training routines — and disabling SME was the path of least engineering resistance. Both theories are bad: one means your security feature is a marketing lever, the other means it was load-bearing on assumptions nobody documented. AMD's silence in the forum threads is what's making people pick the more cynical of the two.
It's also worth comparing what *didn't* happen here against industry norms. Microsoft publishes KB articles when Windows Update changes BitLocker behavior. The Linux kernel mailing list debates for weeks before flipping a default that affects memory protection. Firmware is the one layer where "silent change, no notification" remains an accepted practice, and this is exactly the kind of incident that should end that norm.
If you're running anything that depends on SME — full-disk encryption with keys held in RAM, a workstation with sensitive credentials cached in a long-lived process, a CI runner that handles signing keys — go check `dmesg | grep -i sme` and `cat /proc/cpuinfo | grep sme` right now on machines that have taken a recent BIOS update. The flag may still appear in `cpuinfo` even when the feature is no longer functional, so verify both the capability bit and the kernel's activation message. If the activation line is gone, your threat model just changed without you authorizing it.
For anyone building products on consumer Ryzen — homelab appliances, edge boxes, prosumer NAS units, the entire Framework-laptop adjacent ecosystem — this is a procurement signal. Any security capability that isn't contractually guaranteed in a datasheet is a feature you're renting from the vendor's current mood, not one you own. If memory encryption is part of your security story, you now need to budget for Ryzen Pro or EPYC parts, or move that protection layer up the stack (LUKS with TPM-sealed keys, application-level secret managers, hardware security modules for the secrets that actually matter).
For security teams writing internal hardening guides: stop citing SME as a mitigation on consumer AMD hardware. The capability is now "present until a BIOS update says otherwise," which is not a control you can put in a compliance document. The same logic should be applied skeptically to any other firmware-toggleable security feature on consumer silicon — Intel TXT, TME, the various IOMMU enforcement modes. Audit them, document the AGESA/microcode version where you verified them, and re-verify after every firmware bump.
The most useful outcome here would be AMD breaking its silence with a clear statement: either "SME on consumer parts was never supported, we're removing it, here's the SKU you should buy if you need it," or "this was a regression, here's the AGESA version that restores it." Either answer is workable. The current non-answer is the worst option, because it leaves a population of users with a degraded security posture and no way to plan around it. Until AMD says something on the record, the safe assumption is that any defense-in-depth feature on consumer silicon can vanish in the next firmware push — and your runbooks should reflect that.
From yesterday: "Users cry foul after AMD stripped memory crypto from its consumer CPUs", https://arstechnica.com/security/2026/06/users-cry-foul-afte... ( https://news.ycombinator.com/item?id=48559827 )
It's pretty crazy that we have this entire segment of features that companies artificially restrict from the average person and overinflate the price of, for no real reason. GPU virtualization is another example of such a feature.The market segmentation arguments don't really work either,
I had this enabled as it protects against RAMbleed/ECC errors, so it's not limited to physical attacks.
I don't know how this works but does this mean if someone gained physical access to your locked running computer, they could gain access to your full encrypted drive and anything saved on disk?My reasoning there is if you used an encrypted drive, the decryption key you type when booting up woul
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
This was never marketed as a feature of the consumer CPUs and if some malignant actor does get physical access to my (consumer) hardware, then them being able to read out bytes through cryo-freezing the RAM really isn't high up on the list of things I'm going to worry about.