AMD silently removes memory encryption from consumer Ryzen CPUs
tomshardware.com
tomshardware.com
As far as AMD is concerned, this was never supported, nor documented. Now pulling the rug with a firmware update isn't a very nice thing to do, but maybe they've had some actual reason for that beyond "this shouldn't be enabled". Nobody should expect undocumented and unsupported features to just continue to work in perpetuity, simply because they did work at some point in the past.
Maybe this is the only thing that concerned them but not the only thing they knew very well. AMD knew that this was widely used by consumers and that every motherboard manufacturer exposed the option to the user. They pulled the rug legally, knowing that all those many people standing on the rug will fall on their ass.
> Five guys moving a server to a new datacenter without shutting it down. Without cutting it off from the internet. And as using a car would have been too easy, they used public transport.
* https://www.youtube.com/watch?v=vQ5MA685ApE (DE audio, EN subs)
See also perhaps:
> The HotPlug allows hot seizure and removal of computers from the field to anywhere else. The HotPlug's patented technology keeps power flowing to the computer while transferring the computer's power input from one A/C source (such as a wall outlet or power strip) to another (a portable UPS) and back again.
* https://shop.digistor.com/products/hotplug-field-kit
* 2007 potato-quality demo: https://www.youtube.com/watch?v=erq4TO_a3z8&
If anything, thats an indication to me to make a HA setup so you can power down 1 member.
Im not going to watch a video, honestly, but HA with a front-facing Zookeeper and sharded Postgres isnt super hard. Can be if you didnt initially plan for it.
Ideally, you need an odd amount of quorum machines to properly handle split brain decisions... But if its a money issue, you can technically get by with just 2, and accepting a possibility of split brain.
> We created this product for our Government/Forensic customers
I wouldn't say that I miss those days, but there's some good nostalgia there having done some things that feel pretty similar (early 2000s). Not quite to that extreme though.
Highspeed Highway Halo
Even if you have the ability to remotely enable new features:
1. You shouldn’t use the same ability to disable existing features.
2. You shouldn’t enable them, either! It should be opt-in. Any kind of change has the potential to break something. Just don’t be changing my hardware without me initiating the change.
> Just don’t be changing my hardware without me initiating the change
In this case it seems to have been disabled in future firmware, so "you" did initiate the change, as you did an firmware upgrade that included the change. Still, shitty to sneak it in, I agree, but the feature wouldn't literally be there one day then not the next, requires human initiation at least.
I don't know what current case law is but I think that ought to be explicitly illegal. A physical product should be required to maintain the features that it had when it was purchased. Anything else is clearly cheating the consumer.
> particularly for gaming servers
Not "particularly" but that's one example.
Also, it probably wasn't the selling point, but it was the baseline of quality, and probably documented online or in manuals.
Furthermore, accepting this as normal opens the door to further post-sale enshittification of ALL things. Next thing you know, upgrades here and there are going to degrade the quality of products and services just because it wasn't explicitly written (think post-upgrade slowdowns of mobile phones to pressure people to buy newer ones).
This is THE slipperiest slope; and it's just taking place because the deregulation mafia is turning a blind eye to these tech cartels.
Given it was never marketed, it's possible perhaps despite the feature being exposed it never worked correctly and AMD saw fit to just disable it rather than people get a false sense of security through it.
"no one uses it and there is a bug" may invite more questions or panic, but "that's all we're going to say" implies that Mythos found something scary, or that the NSA demanded they all get turned off.
I'm all ears.
https://github.com/amd/firmware_binaries/blob/main/cezanne/P...
AFAICT the situation here is, it should have never been enabled for these consumer parts in the first place.
The market segmentation arguments don't really work either, enterprises are paying the big bucks for more than just these standalone features.
Other software you run is billed relative to your MSU tier. So, if you run z/OS then your cost will be higher if your machine has more MSUs. A weird quirk of this is that there is thing called "IFLs" (Integrated Facility for Linux) which, when I when I first heard of them, I thought was a separate processor designed for for linux. However, it is not. It is actually the same as the regular processors that run z/OS etc, the difference is that is is licensed exclusively for running Linux (or like z/VM to run linux counts too). The reason for this is to enable shops that want to run linux and needed extra horsepower to do so, but didn't want their z/OS bills to go up because they purchased more MSUs. So, despite buying more of the processor capacity within the mainframe, it doesn't count towards the "MSU" number that impacts the cost of various software because you are using with one type of software vs another type of software.
so I'm saying it's even WORSE than being able to pay to upgrade. as it's more wasteful
I really don’t understand the subscription model applied to a physical piece of equipment that has no digital maintenance overhead.
It isn't double dipping, in no scenario does it make sense to physically make two models, it is more expensive for no gain. The question is just how you charge people for it.
(Now subscription seems like an awful model, but a paid upgrade for some people makes sense to me)
A subscription fee = Drake no, that’s totally ridiculous and unholy.
I don’t know what the fee is but it’s have to be lower when aggregated over the car’s lifetime than what the one-time unlock would cost to make sense - and I’m fairly sure it’s not lower.
Second, your argument kind of holds if it’s a one-time unlock fee, but falls apart under the subscription model. That’s a total revenue stream cash grab.
SR-IOV ("true" GPU partitioning) is targeted at the Arc Pro/DC GPUs only, not the desktop variants.
That leaves Intel in the same boat as the others these days: you can either pass the whole GPU through or buy a non-consumer variant for proper hardware virtualization (or try to hack it).
All that being said, in my opinion, it needs to come with several features:
1. no subscriptions for something that is just a one time unlock 2. It needs to be legal and protected for customers to figure out how to unlock it on their own without purchasing the unlock.
I haven't thought enough to have a strong opinion on the exact situation you describe (where it is present and an unlock isn't available at any fee), other than to say I'd still argue strongly that customers figuring out how to unlock it on their own should be legally protected.
Many of traditional block cypher encryption modes do `cypher_text = plain_text ^ block_chypher_output` with the differences being what goes into block cypher input. This means that single bit flip in cypher text maps 1:1 to bit flip in corresponding decrypted block (and sometimes uncontrolled flips in next block). For malleability prevention full protocols would use MAC in addition to encryption. That's not very practical for memory encryption. Ability to use of various chaining modes is limited since you don't want to re encrypt whole ram when single byte changes or otherwise reduce parallelization of ram processing. Only traditional mode which doesn't degrade parallelization is counter mode, but that's fully susceptible to controlled bit flips. Maybe they can use chaining at cache line or cache block level.
This made me think. If the memory controller is already implementing encryption with limited chaining at block level. It wouldn't take much more additional resources to include hardware MAC as well, thus providing much stronger error detection (not correction) capability compared to typical ECC. The fact they aren't advertising it makes me think they aren't doing it, thus using some kind of counter mode variation and thus no extra bitflip protection.
My reasoning there is if you used an encrypted drive, the decryption key you type when booting up would be stored in memory for the duration of that boot.
This seems alarming because it means if someone broke into your living quarters they can bypass all forms of disk encryption if your machine was on and locked. Encrypting your disks seems like a reasonable thing to want to do with consumer grade hardware.
It causes many stability issues, as to my experience.
The attack is sophisticated, Mr.Nobody, generally, should not worry about expensive cryogenic attacks - three letter guys would extract your key with a wrench.
I mean the change is bad - it undermines already damaged trust, but the "average Joe" is extremely unlikely to be affected directly.
There are many much cheaper ways to force you to give up your keys.
In my experience it very much does not, ram instability with this feature indicates a hardware issue same as with ECC.
>Mr.Nobody, generally, should not worry about expensive cryogenic attacks - three letter guys would extract your key with a wrench.
This is disingenuous framing. There exist valid threat models for average people between thieves and three letter agencies. Police forces and organized crime have been known to use ram freezing, the former is not known for wrench attacks. That scenario is only good for hand waving real concerns anyways.
Something being illegal does not imply it doesn't happen though.
and recent Supreme Court decision that upheld its constitutionality:
https://www.algoodbody.com/insights-publications/password-pr...
Suing after the fact is a valid strategy and in free countries this would allow you to exclude illegally obtained evidence or evidence lacking proper chain of custody.
Are people still using this to justify no encryption? that comic sure did a lot of damage.
Mr. Nobody should be able to decide how much they want to protect themselves. If it's unstable maybe Mr Nobody is fine with it.
Raising the cost of achieving this to enterprise budgets, just because, seems suspect. Specially when there are so many attempts to undermine secure computing by the powers that be. [1] [2]
> There are many much cheaper ways to force you to give up your keys.
Yes, but that requires the Mr Nobody knowing you have access to them, which in itself is a big deal.
But let's think about it, why would they torture Mr Nobody by wrench? News stations would like to hear that, or do you think they will make Mr Nobody disappear too? Would they take those risks for a Mr Nobody?
Maybe the most realistic scenario is that people sometimes can hold onto their passwords. Scumbag or not. [3]
[1] https://en.wikipedia.org/wiki/Apple%E2%80%93FBI_encryption_d... [2] https://en.wikipedia.org/wiki/Chat_Control [3] https://arstechnica.com/tech-policy/2020/02/man-who-refused-...
Whilst I hate companies paying engineers to make things worse just to segment their market; I am not really seeing this as an important feature outside the data-center? If an evil-maid has hardware access they hack the USB and/or PCI not the RAM surely?
Probably not from a legal perspective, but morally yes. Apple cause batterygate with good intentions but sneakily. Not being transparent is what shot them in the foot. AMD didn't learn anything or thinks this is small-time so no blowback (sadly they might be right).
Sure, the Apple's intentional performance degradation of older iPhones was caused by only good intentions, not a form of planned obsolescence in any way. How could it be?
What if said feature was sneakily and silently added in the first place? Wouldn't it be acceptable to sneakily and silently removing it in the future then? Or regardless of if it was documented/announced or not, removing anything sneakily and silently is bad?
The only mistake AMD potentially made here is not being transparent why it was disabled.
we could all be burning our own tiny ~300nm feature size ICs at home for around the price of a blu ray burner and a dark room setup. Our silicon limitations are not for a lack of hardware, but rather a lack of freedom.
> ~300nm feature size
Can you point to a specific regulation that prevents me from crafting shitty semiconductors in my shed? I am pretty sure there are entire YouTube channels dedicated to this.
There's a big difference.
You can, too, without much/any paperwork... if you have the funds.
And there's been talk that now the so-called "AI companies" will start using more CPUs as well, due to "personal agentic agents", so I hope that people won't be priced out of CPUs too...
https://arstechnica.com/security/2026/06/following-user-outc...
Too many people downplaying this as a simple business decision from AMDs side but the response here is what really makes this a story.
Where there's smoke, there's fire.
If the NSA wanted to say no they'd just ask for some kind of back door and call it a day.
I wouldn't be surprised if lower hardware prices and weaker demand for everything are more likely to lead to more feature rich products to encourage sales, and higher hardware prices hurting sales volume leads to a natural/expected contraction in feature availability to compensate for lower sales.
But yeah 95% of the consumer market don't care about this and it's only adding unnecessary costs
Any extra cost would be mostly due to power consumption and testing that the feature works (which they probably don't do for consumer skews anyway). The area of silicon used by the feature is probably negligible, from the manufacturing cost perspective it's cheaper to avoid any unnecessary design differences between skews.
should also set the MemoryOverwriteRequestControlLock (MorLock v1/v2) if you don't want it ever changed (on 'clean' reboot MOR is usually unset to facilitate a faster boot).
there is still the problem of actually triggering the reboot.
This has implications beyond simply securing against physical access attacks, but also protects against rowhammer and its ilk.
Between this and their recent botched software update verification I'm getting a little wary of AMD.
Everything is done silently and quietly nowadays.
It prevented it by having a hardware module on the CPU's memory controller that AES encrypts the contents you are sending to DRAM, and decrypts it before reading it back to the CPUs memory structures. All with hardware keys completely invisible to software (and one that is basically impossible to manipulate physically).
And you need to be able to do it multiple times for the bits of memory that you want to snoop on, to be the bits that survive the transfer.
A feature that was possibly accidentally enabled on consumer chips is now being disabled. I would guess that the number of owners of consumer chips who also relied on them for encryption is exceedingly small.
The primary concern persists. The manufacturer has an exceptional amount of control of the state of your CPU most of which you cannot change and an unknown chunk of which you cannot even see. We are sort of playing in a fools paradise.
They either have that control or they don't.
So it's quite possible they were doing the same with TSME, and either made a rude marketing decision that the people using it on consumer chips would probably pay for PRO chips if they were prevented from doing so, or kept getting people attempting to RMA the chips for a feature they never said worked on them not working, or there's some systemic flaw in the consumer chip's implementation that they didn't feel like trying to qualify fixing versus just killing the not-guaranteed support.
Hard to guess without more data than just them going silent about it.
I guarantee you that there's one small company that put 1,000 of these chips in a server room or datacentre though, and they're now completely boned.
Bro what are you smoking? The highly paid and experienced engineers designing these chips could have "possibly enabled" the feature on consumer chips.
The chips were designed with the feature as it is cheaper to do everything right from the get go and disable functionality rather than design a less capable chip then tack on the feature afterwards, just as the consumer versions of Windows are the server versions with functionality removed.
You have to store the encryption key in CPU registers and ensure it's not saved to RAM during task switching or power suspend operations. Tresor used x86-specific debug registers for it, but you could potentially use unused SIMD registers if you masked-off the CPUID bits for them and disabled them for access by user-space.
But securing against attacks from a hostile hypervisor or a server provider needs more than just memory encryption, because they can intercept any part of the boot process and control the hardware/firmware that can lie to your kernel.
To counter that you'd need something like AMD SEV(ES/SNP) with measured boot and remote attestation to switch the only thing you trust to the CPU manufacturer (best you can do IMO).
Interesting insight. Any reason why the key can't be kept exclusively in the secure enclave / trusted platform module / crypto coprocessor?
There wasn't any such features for x86 when the patch was created, other than AES-NI.
Many hardware platforms that have TPM, have it connected via a low-bandwidth LPC bus which would have nowhere near enough bandwidth for demand decryption/encryption of memory pages.
Hardware vendors can apparently turn these security features off as they wish, even if the hardware supports and was shipped with it :)
Ah, of course. I was more thinking along the lines of "CPU loads the key for decrypting RAM directly from the TMP into registers, and reloads it from there after waking from suspend or after a task switch has refilled those registers".
IMO using the specialized CPU instructions (AES) is not clever because they'd obviously have backdoored that instruction to simply remember all keys that were used.
It's part of a defense-in-depth approach that Europe unfortunately needs as Europeans are considered as foreigners without any human rights by the five eyes community. America and their major tech leaders have made that abundantly clear to Europe, including the hitler salute as cherry on top.
I'm quite sad we have reached this situation, but if one is serious about security these things need to be discussed and if possible implemented.
Silent enshittification in the name of updates is getting out of hand. There are several evidences that downgrading BIOS/AGESA to below 1.2.7.0 to 1.2.0.3 brought back TSME for their AMD cpus.
I downgrade my bios as a price for my blind trust on AMD, and yes TSME is back.
You lost my trust AMD. The lesson learned is that if your PC with AMD cpu is stable, don't do any bios upgrade, as AGESA in the bios is adversarial to you, the users of AMD cpu.
If you're serious about privsec you should use GrapheneOS.
But even then? can you really trust the research and information about how to produce those ICs if you have not conducted that research yourself personally?
Did anyone even use this feature?
Yes it is dishonest to remove features but from perspective AMD disabled a feature that never worked in the first place. The feature never should've been advertised as enabled.
Then AMD created their EPYC variants, and it wasn’t clear what the difference was between the consumer & Epyc models.
Like the article hits spot on right at the start, it has nothing to do with needing to differentiate Epyc somehow and everything to with differentiating the PRO versions of the consumer CPUs:
> was suddenly no longer available on AMD CPUs outside the company's Pro lineup
The PRO variants are just the standard consumer CPU sold at a $ premium for enterprise targets. They have remote management firmware enabled, get longer firmware and support lifecycles, FIPS certification, and, now, memory encryption over the consumer branded version of the same CPU.
Consumer:
https://www.amd.com/en/products/processors/desktops/ryzen/90...
EPYC variant:
https://www.amd.com/en/products/processors/server/epyc/4005-...
>>Makes sense. The ECC in consumer line is what created an entire market for use in inexpensive web hosting. Then AMD created their EPYC variants, and it wasn’t clear what the difference was between the consumer & Epyc models. reply
"True" Epyc has always had a differentiation from the consumer line in the scaling+features, Ryzen PRO has always had a differentiation from the consumer line in the features, and "fake" Epyc 4000 has always had differentiation from the consumer line in the same way as PRO had/has.
Of all of the combinations, only the newer Epyc 4000 line compared with the pre-existing Ryzen PRO line have actually lacked differentiation from each other and this change in encryption support on the consumer line does not help with that.
For most consumer users, RAM encryption primarily adds power consumption and heat generation while providing little practical benefit. They simply don't face many of the threat vectors and attack scenarios that certain industries and enterprise environments must contend with.
There are many people, myself included who opt to use security features like this. All this does is reduce security for folks without any legitimate reason. “Power consumption” is absolutely not a valid excuse to completely disable it.
I’ve been a fan of AMD for a while now but they’re really jumping the shark these days. It’s a real shit situation we’re all in because of the lack of competition in consumer CPUs. I can only hope things like RISCV take off sooner than later.
this is approximately the same discussion as with ECC RAM: the benefits vastly outweigh the slight performance loss and die area increases.
Memory encryption, on the other hand, provides absolutely no benefit to 99.999% of users. If you consider yourself to be such a high value target that you suspect someone might gain physical access to your hardware without your knowledge and carry out extremely sophisticated hardware attacks to extract your data, you are a tiny minority and it makes sense that such niche protections would require buying specialized hardware. Even then, the odds of such an attack being chosen instead of a far less sophisticated software-based approach are also tiny.
Of course, if the hardware itself supports the feature and AMD simply decided to disable it, that's still a shitty thing to do, but let's not pretend that it is in any way comparable to ECC.
No benefit for 99%? people said the same about FDE. Just as there is not a good enough excuse to not validate integrity and availability of data, it is not for confidentiality when its very much technically possible to do so.
I also believe that a strong reason that Optane pdimm's failed, was that it was only available on enterprise servers so hackers didn't get a chance to play with it and build software that took advantage of this special hardware.
Just look at how specialized Infiniband is, even though its awesome and has some great use cases. If it was a commodity tech, there would be 100x times more applications/software that took advantage of it.