New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
AMD removes RAM encryption from Ryzen consumer CPUs, reactivates it after community backlash
Original article on Ars Technica: https://arstechnica.com/security/2026/06/users-cry-foul-after-amd-stripped-memory-crypto-from-its-consumer-cpus/
AMD's response to Tom's Hardware's inquiry: https://www.tomshardware.com/pc-components/cpus/amd-will-reinstate-memory-encryption-on-ryzen-9000-cpus-through-a-bios-update-in-july-tsme-is-coming-back-after-valuable-community-feedback
GitHub open issue with the full timeline: https://github.com/AMDESE/AMDSEV/issues/292
Personally, I'm not sure if they removed it to push people who need this feature to upgrade to a PRO-line CPU or if a three-letter US government agency reached out to them. At least it's being reinstated now.
Comments
Consumer users have no use for it. This only make sense when running VMs, and you want to protect your guest memory from the Hypervisor. Makes more sense if gaming companies reached to them, because it will potentially make various anti-cheat engines useless. Also, there is a performance degradation when you use it. And they want to look nice and shiny in benchmarks. Remember the performance drop with Spectre and Meltdown, ZenBleed? Even worse with AMD SEV-SNP. Consumers want good geekbench scores, not security.
I would disagree with that to some extent. Most consumers use Windows so they have BitLocker enabled by default even though they don't realize it. If someone steals their laptop or PC, it's easier nowadays to perform a cold boot attack to retrieve their data (at least if the RAM isn't soldered). Besides that, if the silicon already supports it, why disable it? There's no good reason really.
As for performance, it doesn't have a horrendous impact, it's only AES-128 which AES-NI helps with a lot. See Cloudflare and Oracle's experiences: https://blog.cloudflare.com/securing-memory-at-epyc-scale/ https://blogs.oracle.com/cloud-infrastructure/perf-impact-of-confidential-computing-on-oci-vms
Those are desktop class CPUs.
Cloudflare is not a good benchmark since their workload is different - they transit data,
not doing CPU heavy tasks on it. Well, at least not to an extent of a gaming-focus CPU.
That's debatable, but we'd need to see benchmarks of RAM encryption for gaming specifically to know the actual numbers.
FWIW, check Onidel's yabs with and without:
https://kb.onidel.com/hc/kb/articles/1771943583-sev_snp-verified-boot-and-memory-encryption
This is similar to the numbers I saw. Quite noticeable when you need to switch contexts
between kernel and userspace, which directly affects disk I/Os.
Ah yeah fair enough. I have a 9800X3D with a MSI B850 Gaming Plus mobo (and a RTX 5070 Ti), I updated my BIOS recently so maybe TSME has been deactivated but if it hasn't I should run some benchmarks.
Hm, in this article I attribute the slower IO is mostly due to data being copied back and forth in shared SWIOTLBs when talking to external devices. This all happens in kernel space.
In general, a single YABS should not generally be treated as a benchmark. That section was included more to give an idea of what to expect. However I really appreciate the mention
Phoronix did better evaluation of SEV-SNP performance on EPYC Turin 9005 CPU:
https://www.phoronix.com/review/amd-epyc-9005-sev-snp
There are also some measurements of SEV-SNP effects on latency and overall data throughput in this article.
Worth noting this thread is about TSME, not SEV-SNP. Those are essentially two different things with TSME focusing on encrypting entire system memory, while SEV-SNP was specifically made for virtualized environments with different encryption keys used per VM.
And it's a sham and a complete security theater that cannot be relied on. Good riddance if they'd remove the entire concept altogether. You cannot protect from a hostile hypervisor, if that's a concern, get a dedi.
I mean, it makes sense for AMD and Intel to develop and improve these hypervisor security features because big cloud providers like AWS, Azure and so forth need them. Which is also why security researchers (academic and industry) are trying to find vulnerabilities.
You absolutely can protect against a hostile hypervisor, although with physical access and enough expertise, it's currently possible to bypass. But if all you have is a compromised node, you can't successfully attack the guests if the guests are using SEV-SNP alongside proper remote attestation. Side-channel attacks are another issue, though...
However, OP's posts are about full memory encryption, not per-guest encryption. The full memory encryption is only there to protect against cold boot attacks and bus sniffing. It does not protect guests.
Can we be realistic here for a moment? If a provider is hostile, actually read my previous
posts, I demo how to show fake CPU, yabs...But this is not the main threat model here.
The main one (I guess) and should be (also, I guess) are malicious neigbours on the node.
And AMD SEV-SNP completely protects from that, again, we are excluding hardware, physical attacks when you can attach a hot patched debugger on the memory bus. Cmon my friend, let's put a little pratcical story here, nobody will make this effort for 100$/y VPS. I have, and demonstrated, much worse UEFI attacks against physical machines.
To defend against UEFI-level attacks, you'd need DRTM or SRTM (and it won't protect very much against a sophisticated attacker with physical access). Still quite possible, though, since UEFI updates cannot overwrite the bootblock.
If the provider is hostile, TEEs can protect guests if and only if the provider does not have physical access to the node.
I've never said that it's a vital feature for a $100/year VPS for most threat models, of course (and virtually no hobbyist is going to go to the effort to perform actual remote attestation). But that doesn't change the fact that it does protect against a malicious hypervisor, unless there are existing software-exploitable implementation bugs, which there may be.
But again, OP's post is not about SME or SEV-SNP, but about TSME which has nothing to do with hypervisors.
Can you demo it against a malicious hypervisor? That's the question.
My demo lab is simple. Be a remote attacker, I will give you root on HV.
A guest will have SEV-SNP enabled, plain AES, you can use tools like aeskeyfinder.
Volatility, memdump, whatever you want. Can you do it without hot access to hardware?
I bet here 10,000$. Hypervisors on me, you get root to the hypervisor, no physical access.
Fair? I think for most threat models - it is.
Is there like escrow on LET? I will put 10k there.
Does it actually re-use the AES-NI hardware? I thought it was more tightly integrated into the MCH.
I think you're misreading me. I said it does protect against a malicious hypervisor, not that it doesn't.
The most I could pull off is basic side-channel attacks against vulnerable software, which is of course out of scope.