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.
Reminds me of that Seinfeld episode where George tries to move a Frogger arcade machine without powering it off in order to not lose his high score leaderboard.
> 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.
> 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.
Thanks for sharing the video of moving the server.
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.
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.
My oven has a proofing feature. It wasn't really advertised, it's just there. I like that feature and I use that feature when baking.
If one day my oven manufacturer pushed an update which removed my proofing feature, I'd be upset.
The same could be said for encrypted memory. If you as a computer owner discovered and turned on encrypted memory because you wanted to feel a bit more secure about your hardware getting stolen. You'd probably be upset that on a normal firmware update that feature suddenly went away. Not because the hardware doesn't supported it or didn't support it. Not because AMD's firmware didn't or couldn't support it. But because someone in an AMD product management team said "Woopsie, that's an enterprise feature, we better disable that".
Completely different story if these CPUs never supported that feature. Completely different story if future CPUs didn't have that feature or had it disabled in firmware. Heck, even a different story if with the disable AMD also said "We disabled this because there's an unrecoverable fault in the memory controller which causes memory corruption."
I have to assume the reason wasn't because of a bug in the feature, but rather because management decided the feature wasn't supposed to be there.
I'm not a user of it, so It's not hurting me personally. But if I had read about how Ryzen CPus support encrypted memory, and had chosen a Ryzen CPU for that reason, I think I'd have a pretty good reason to be upset that the feature I needed from a hardware product I bought suddenly vanished in a firmware update.
Because I think ethics goes further than "bad thing happened to me", I've formed an opinion that this is a pretty shitty move.
Transparent communication would have been appreciated nonetheless. You have customers not just lawyers on the other side, it's not just about making sure you're legally covered.
Let me give you an analogy: If you e.g. figure out some undocumented endpoints for a REST API, which are intended for internal use only, and started using them, do you expect the developers to inform you about changes?
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.
There is more nuance to this. Let me give you a better example that actually happens — SSDs. Manufacturer will tell you some miniscule amount of specifications, such as that the drive reads and writes some amount of MB/s. That's basically the only spec you get. Reviewers review this drive. It is a really good drive, dedicated controller, MLC/TLC flash, all the good stuff. It gets raving reviews. Some months after this, during which the drives have been selling like hot-cakes and have been recommended everywhere, the manufacturer swaps parts, without creating a new SKU/model. Some examples are swapping TLC flash for QLC flash, making the SSD DRAMless when it had a dedicated RAM before and such, all negatively affecting the performance in some way. After the changes, you can still read/write with the advertised speeds, but only for 10GB instead of indefinitely or the drive has much worse latency or what have you, you basically got bait-and-switched and bought an inferior product to what was expected. The question is, is this ok? I think it is not ok, even though the manufacturer technically did not promise all the seemingly undocumented stuff (although one could argue that it has been documented by the reviewers).
> As far as AMD is concerned, this was never supported, nor documented.
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.
That's an asinine take. We're not talking about a remote subscription service changing an undocumented implementation detail. Physical artifacts shouldn't lose features due to the remote action of the company that made them.
So reading between the lines, you're saying it's bad for AMD to disable undocumented features because people still might have bought them for those undocumented features, particularly for gaming servers?
You shouldn't be remotely disabling hardware features in my opinion at all. It's not really like changing an API or something, this is like an update removing something from your car or another appliance years after you bought it.
> You shouldn't be remotely disabling hardware features
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.
Yeah, basically you'd trade uncertainty for the ability to remotely enable/disable hardware features not ready at launch I understand, which totally makes sense as a position, I probably agree with you. I think from AMD's side they like the option of being able to remotely enable things though, so new software updates in the future could be major releases enabling functionality that wasn't quite ready at launch. But, I suppose the uncertainty is the tradeoff here.
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.
Overall I agree with you, and aim for the same, as a professional user I can't really have my environment and hardware change automatically, I really despise that too!
> 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.
IIRC, this memory encryption function can let a hypervisor tell the platform to use different encryption keys for different virtual machines. So even if somehow a compromised VM managed to read data from a neighboring VM theoretically they'd get garbled, encrypted data.
That is not in this one. That is only the datacenter one(SEV) This one (SME) is a single machine wide key and it doesn't have integrity protection either.
And? do you worry about the gaming server owner's neighbour breaking in, freezing the ram, quickly transferring it to another machine and reading it off?
This doesn't matter; it's post-sale enshittification... They didn't even wait to make the next model shittier!
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 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 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.
Physical Access to a computer is almost always the fastest and easiest way to crack it down. Additionally, both Windows's BitLocker and Linux's dm-crypt are data at "rest" encryption. They are not responsible for the safety when your machine boots up. MAC and user password are the proper method when it's running.
Yes. Also depending on the implementation (ie if it's not an outdated Intel machine) it is presumably also vulnerable to snooping the memory bus while it's running. Note that this active attack applies regardless of encryption and impacts even enterprise SKUs. https://tee.fail/
This feature was off by default in all the mobos I've seen.
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.
> three letter guys would extract your key with a wrench.
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]
Unless you live in North Korea, China, Russia, UK, France, Australia or Ireland it’s still illegal to coerce or force someone to give up their personal keys or passwords, so this feature is still useful against some law-bound adversaries in free countries.
The West just a few years ago declared that at airport entry points, no one is including their citizen is not protected by any law when it comes to providing access to your private stuff.
What are you trying to prove? He never said you're wrong, just the fact that something is illegal doesn't mean that it won't happen to you, just that it's illegal - those are just words written in a book somewhere. Even so-called law bound adversaries break the law all the time. A cop beating you senseless or breaking into your home is illegal, but it happens all the time. You're welcome to sue after the fact.
This is not relevant to memory encryption, the police could just plant any false evidence. You use video camera/CCTV and other evidence gathering to document such illegal police action.
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.
In a previous administration they apparently concluded that while the government can't violate your first amendment free speech rights, they can ask a third party to do so. So what makes you think that the CIA won't hire blackwater or the crips to hit your toes with a ball peen hammer until you tell them what you want to know, and then walk away having not violated your constitutional right to privacy and not incriminate yourself?
I don’t want to get into specifics because ultimately it just comes down to the logical argument that just because a strategy is not by itself successful against all possible threats it doesn’t mean it’s worthless. By this logic you wouldn’t lock your front doors.
>It causes many stability issues, as to my experience
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.
Well, I've experimented with this feature on several platforms (both ECC and non-ECC) starting with TRX40, most of the times I've been just getting hard freezes at GPU driver initialization. If it boots - it usually hangs when a VFIO VM spins up.
How can they not anything to say about it? I demand answers both why they sneakily added it and then why they sneakily removed it. Especially if it was a burgerland government intervention.
Yes, it's AES with a tweak based on the physical address. It adds some protection from RowHammer and the like because flipping a bit in encrypted memory is catastrophic, while it can be done in a controlled manner if it's not encrypted.
Whether you get controlled bit flip depends on exact encryption mode used. Haven't seen any document with enough technical details on how exactly their encryption scheme works.
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.
Which encrypts each cache line with a key unknown to the attacker. This means an attacker can't target individual bits. Every change affects at least one AES encrypted block. It's much stronger than any normal defence against row hammer in that regard because flipping a single bit in plaintext changes ~half the bits in the ciphertext. It's similar to how Apple uses always on disk encryption instead of the normal means to limit run length in their NAND flash controllers. If the encryption is "off" it just means the decryption key is stored somewhere in the trusted enclave.
it's exactly why we're not allowed a competitive market for CPUs
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.
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.
IP laws. You personally might be able to do this. But should you attempt to sell a device that makes it easy for anyone to do, you will get sued into oblivion.
If it can be silently removed was it a security feature?
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?
if anyone does it sneakily, there is alleged wrongdoing attached to it. I can imagine multiple scenarios like some well-known Israeli company "selling their software only to governments", paying quite amount of money for it, because they were unable to break this one.
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).
> Apple cause batterygate with good intentions but sneakily.
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?
If you ever had to use an iPhone that would just shut off randomly with like 30% battery "remaining", you'd probably be singing a different tune and appreciative your device became somewhat more usable with the changes.
I'd expect the battery charge estimation to be recalibrated to account for the reduced capacity, not the hardware being deliberately hobbled to hide it.
I heard the old batteries, when giving high current would depress voltage long enought to trigger the shutdown, plausibly long enough to mess up the processor if it didn't shut down, but could genuinely give a lower current for a long time, such that rounding the charge down to zero would be harmful. It's easy to argue it's better to keep the phone slower then just shut it down when it can't reliably go fast.
> Sneakily and silently removing a feature in a firmware revision is not acceptable
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?
I would be fine with this if it meant CPUs became slightly cheaper, but we know that's not going to happen.
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...
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, enterprises are paying the big bucks for more than just these standalone features.
Reminds me of subscription heated seats in bmw cars. The hardware is already there, you paid for it and you can’t use it unless you give the automaker a revenue stream on top of the tens of thousands you already paid for the car.
Why did the NSA wait 9 years to say no & why does that explain the coincidence of the feature being supported in the PRO variants of the same CPU, which just happen to cost more?
If the NSA wanted to say no they'd just ask for some kind of back door and call it a day.
No clear difference beyond the scaling to 6x the memory channels, 24x the memory capacity, 12x the core count, 6x the PCIe lanes, and ability to double (or nearly double) these with a 2nd socket. There are also a few features, like per VM memory encryption, which have only ever been on Epyc (and "real" Epyc, not just any Epyc branded consumer platforms).
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.
The Epyc 4585PX falls into the `(and "real" Epyc, not just any Epyc branded consumer platforms)` note. I.e. it is the same CPU as the AMD Ryzen 9 PRO 9965X3D, branded differently because it is certified against "server" branded motherboards instead of "standard" PC motherboards (same socket/chipset though, outside firmware validation the two are swappable). It carries none of the actual Epyc feature sets, just the PRO features, and the feature differences are therefore the same as any other PRO CPU.
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 this serious about security, then manufacturing your own hardware isn't good enough, you need to create your own big bang to seed your own planet to source your own helium to be used in the production of your own ICs.
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?
Everyone jumping up about "enshitification". I tried to enable this feature on QEMU and it broke my VMs because the secure memory system was board-line hopelessly broken/non-functional.
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.
It's not bad at all. Long story short, this feature prevented people stealing your ram stick off of your machine, super-freezing it and quickly moving it to their machine before the charge runs out and read off whatever bits are still left intact.
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.
> To be fair to AMD, there is no clear indication that the company ever publicly advertised TSME as a consumer Ryzen feature.
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.
How can manufacturers simultaneously have exceptional control over flags and not enough control to know what flags are enabled on their shipping products?
AMD, historically, has taken a "we don't test enterprise features on consumer SKUs, but we don't fuse them off if you really want to qualify it or let them try it" approach to e.g. ECC on consumer chips with Zen.
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.
They always had control. Awareness is a different thing. You could just as well ask "if you've written every line of code, why did you write that bug?".
I'm trying to progress the discussion past "we don't know if it was intentional". We know it was intentional. What was the intention of having it on before and what is the intention of turning it off?
AMD has limited control over what motherboard manufacturers do. And there have been plenty of examples demonstrating motherboard vendors don't fully understand what they are doing. Stuff like shipping builds with example/placeholder keys, ridiculous voltage settings which destroy the cpu.
Even if motherboard vendors don't have full control to configure to freely change every flag, they probably have access to some kind of debug/development firmware which has a lot more features enabled than what you would have in consumer builds.
> A feature that was possibly accidentally enabled on consumer chips is now being disabled.
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.
I wonder what the additional power draw of these features would be. Parenthetically, I wonder often about the energy impact of all these HTTPS localhost links, and is there a point where defense-in-depth has to give way to other concerns?
But yeah 95% of the consumer market don't care about this and it's only adding unnecessary costs
Consumers were always capable of disabling it themselves if they didn't need it. The performance impact seems to be ~3% on average, impact on power consumption is probably similar or less since any extra delay idling can destroy performance while not having as big impact on power consumption. https://www.phoronix.com/review/amd-memory-guard-ram-encrypt...
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.
It's a shame there is no software-based memory encryption included in the linux kernel. Especially cloud providers can easily snoop all your keys and you have zero recourse.
There was a patch called Tresor that did this, but I don't think it was updated for a long time.
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).
Realistically as an European my threat are backdoored components from Epstein's colleagues at five eyes which are used for mass-surveillance of VMs at European hosters such as Hetzner. And every time you add a configuration option like memory encryption it makes their drive-by mass surveillance a tiny bit more difficult and hopefully easier to detect for the sysadmins at Hetzner.
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.
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 :)
> 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.
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".
It is sad that once again we will be exposed to more criminals trying to steal our data. Memory encryption not only allows to secure memory from physical "cold RAM", but also prevents loss of encryption keys as it hides the content during transfer.
For what it's worth, RAM encryption belongs to professional SKUs. It's the right business decision that should have been made from from the very beginning.
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.
I disagree, I play a lot around with enterprise stuff. Its insane that I need to buy enterprise grade hardware that costs 1000x more for lab/experimentation/learning. My only alternative is to wait a few years, and get it from Ebay.
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.
ECC passively benefits everyone, even people who don't know what it is or why it's useful. Anyone can be a victim of random bit flips, it's not a targeted threat.
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.
Memory encryption can help mitigate much lower level attacks such as row hammer, these attacks get patched even average consumer devices.
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.
This is an absurd take since the referenced chips in the article are all desktop parts, and the power usage is dwarfed by any “modern” (within the last five years) GPU.
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 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.
Reminds me of that Seinfeld episode where George tries to move a Frogger arcade machine without powering it off in order to not lose his high score leaderboard.
https://youtu.be/5etwHVarNgI?t=256
From a few years ago:
> 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&
Thanks for sharing the video of moving the server.
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.
Thats rough.
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.
You are not the market.
> We created this product for our Government/Forensic customers
There's plenty of features in products I buy which aren't "marketed", which I nonetheless get upset if are suddenly removed.
You can get upset over anything in the world, including the color of your fridge and that doesn't mean it's a reasonable reaction.
A great example of a non-sequitur. I will interpret this to mean you concede and are not interested in continuing this conversation.
Why are you upset about the removal of this particular “feature”?
Let me put it this way.
My oven has a proofing feature. It wasn't really advertised, it's just there. I like that feature and I use that feature when baking.
If one day my oven manufacturer pushed an update which removed my proofing feature, I'd be upset.
The same could be said for encrypted memory. If you as a computer owner discovered and turned on encrypted memory because you wanted to feel a bit more secure about your hardware getting stolen. You'd probably be upset that on a normal firmware update that feature suddenly went away. Not because the hardware doesn't supported it or didn't support it. Not because AMD's firmware didn't or couldn't support it. But because someone in an AMD product management team said "Woopsie, that's an enterprise feature, we better disable that".
Completely different story if these CPUs never supported that feature. Completely different story if future CPUs didn't have that feature or had it disabled in firmware. Heck, even a different story if with the disable AMD also said "We disabled this because there's an unrecoverable fault in the memory controller which causes memory corruption."
I have to assume the reason wasn't because of a bug in the feature, but rather because management decided the feature wasn't supposed to be there.
I'm not a user of it, so It's not hurting me personally. But if I had read about how Ryzen CPus support encrypted memory, and had chosen a Ryzen CPU for that reason, I think I'd have a pretty good reason to be upset that the feature I needed from a hardware product I bought suddenly vanished in a firmware update.
Because I think ethics goes further than "bad thing happened to me", I've formed an opinion that this is a pretty shitty move.
Transparent communication would have been appreciated nonetheless. You have customers not just lawyers on the other side, it's not just about making sure you're legally covered.
Let me give you an analogy: If you e.g. figure out some undocumented endpoints for a REST API, which are intended for internal use only, and started using them, do you expect the developers to inform you about changes?
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.
There is more nuance to this. Let me give you a better example that actually happens — SSDs. Manufacturer will tell you some miniscule amount of specifications, such as that the drive reads and writes some amount of MB/s. That's basically the only spec you get. Reviewers review this drive. It is a really good drive, dedicated controller, MLC/TLC flash, all the good stuff. It gets raving reviews. Some months after this, during which the drives have been selling like hot-cakes and have been recommended everywhere, the manufacturer swaps parts, without creating a new SKU/model. Some examples are swapping TLC flash for QLC flash, making the SSD DRAMless when it had a dedicated RAM before and such, all negatively affecting the performance in some way. After the changes, you can still read/write with the advertised speeds, but only for 10GB instead of indefinitely or the drive has much worse latency or what have you, you basically got bait-and-switched and bought an inferior product to what was expected. The question is, is this ok? I think it is not ok, even though the manufacturer technically did not promise all the seemingly undocumented stuff (although one could argue that it has been documented by the reviewers).
> As far as AMD is concerned, this was never supported, nor documented.
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.
That's an asinine take. We're not talking about a remote subscription service changing an undocumented implementation detail. Physical artifacts shouldn't lose features due to the remote action of the company that made them.
Many many people use consumer CPUs for gaming servers.
So reading between the lines, you're saying it's bad for AMD to disable undocumented features because people still might have bought them for those undocumented features, particularly for gaming servers?
You shouldn't be remotely disabling hardware features in my opinion at all. It's not really like changing an API or something, this is like an update removing something from your car or another appliance years after you bought it.
> You shouldn't be remotely disabling hardware features
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.
Yeah, basically you'd trade uncertainty for the ability to remotely enable/disable hardware features not ready at launch I understand, which totally makes sense as a position, I probably agree with you. I think from AMD's side they like the option of being able to remotely enable things though, so new software updates in the future could be major releases enabling functionality that wasn't quite ready at launch. But, I suppose the uncertainty is the tradeoff here.
How hypothetical is this situation?
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.
Overall I agree with you, and aim for the same, as a professional user I can't really have my environment and hardware change automatically, I really despise that too!
> 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.
Yes.
> particularly for gaming servers
Not "particularly" but that's one example.
I can't even think of what benefit memory encryption has for gaming servers?
IIRC, this memory encryption function can let a hypervisor tell the platform to use different encryption keys for different virtual machines. So even if somehow a compromised VM managed to read data from a neighboring VM theoretically they'd get garbled, encrypted data.
That is not in this one. That is only the datacenter one(SEV) This one (SME) is a single machine wide key and it doesn't have integrity protection either.
Yes.
And? do you worry about the gaming server owner's neighbour breaking in, freezing the ram, quickly transferring it to another machine and reading it off?
This doesn't matter; it's post-sale enshittification... They didn't even wait to make the next model shittier!
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.
This is FUD. We have no idea the reason why.
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.
the fact they won't tell us why is the concern.
"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.
Why call out FUD when you only have more/different uncertainty to offer?
Spreading misinformation is different to suggesting possible reasons.
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 )
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 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.
Physical Access to a computer is almost always the fastest and easiest way to crack it down. Additionally, both Windows's BitLocker and Linux's dm-crypt are data at "rest" encryption. They are not responsible for the safety when your machine boots up. MAC and user password are the proper method when it's running.
If they have liquid nitrogen and a memory dumping boot disk, or a memory bus interceptor.
Is this still a viable attack in 2026?
Yes. Also depending on the implementation (ie if it's not an outdated Intel machine) it is presumably also vulnerable to snooping the memory bus while it's running. Note that this active attack applies regardless of encryption and impacts even enterprise SKUs. https://tee.fail/
if you have liquid nitrogen and a memory dumping boot disk, or a memory bus interceptor
This feature was off by default in all the mobos I've seen.
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.
> three letter guys would extract your key with a wrench.
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-...
Unless you live in North Korea, China, Russia, UK, France, Australia or Ireland it’s still illegal to coerce or force someone to give up their personal keys or passwords, so this feature is still useful against some law-bound adversaries in free countries.
The West just a few years ago declared that at airport entry points, no one is including their citizen is not protected by any law when it comes to providing access to your private stuff.
Don’t bring your sensitive data to airports.
Well, I live in Ireland but not sure what you refer to.
Something being illegal does not imply it doesn't happen though.
law in question: https://www.irishstatutebook.ie/eli/2017/act/11/section/7/en...
and recent Supreme Court decision that upheld its constitutionality:
https://www.algoodbody.com/insights-publications/password-pr...
What are you trying to prove? He never said you're wrong, just the fact that something is illegal doesn't mean that it won't happen to you, just that it's illegal - those are just words written in a book somewhere. Even so-called law bound adversaries break the law all the time. A cop beating you senseless or breaking into your home is illegal, but it happens all the time. You're welcome to sue after the fact.
This is not relevant to memory encryption, the police could just plant any false evidence. You use video camera/CCTV and other evidence gathering to document such illegal police action.
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.
If you sue them they will just beat you with a wrench again. Courts are imaginary. You should stop resisting. /s
In a previous administration they apparently concluded that while the government can't violate your first amendment free speech rights, they can ask a third party to do so. So what makes you think that the CIA won't hire blackwater or the crips to hit your toes with a ball peen hammer until you tell them what you want to know, and then walk away having not violated your constitutional right to privacy and not incriminate yourself?
I don’t want to get into specifics because ultimately it just comes down to the logical argument that just because a strategy is not by itself successful against all possible threats it doesn’t mean it’s worthless. By this logic you wouldn’t lock your front doors.
>It causes many stability issues, as to my experience
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.
Well, I've experimented with this feature on several platforms (both ECC and non-ECC) starting with TRX40, most of the times I've been just getting hard freezes at GPU driver initialization. If it boots - it usually hangs when a VFIO VM spins up.
How can they not anything to say about it? I demand answers both why they sneakily added it and then why they sneakily removed it. Especially if it was a burgerland government intervention.
I had this enabled as it protects against RAMbleed/ECC errors, so it's not limited to physical attacks.
Are you sure? I thought it's just AES without any authentication.
Yes, it's AES with a tweak based on the physical address. It adds some protection from RowHammer and the like because flipping a bit in encrypted memory is catastrophic, while it can be done in a controlled manner if it's not encrypted.
Whether you get controlled bit flip depends on exact encryption mode used. Haven't seen any document with enough technical details on how exactly their encryption scheme works.
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.
Surely ECC already does that. You don't need encryption.
Which encrypts each cache line with a key unknown to the attacker. This means an attacker can't target individual bits. Every change affects at least one AES encrypted block. It's much stronger than any normal defence against row hammer in that regard because flipping a single bit in plaintext changes ~half the bits in the ciphertext. It's similar to how Apple uses always on disk encryption instead of the normal means to limit run length in their NAND flash controllers. If the encryption is "off" it just means the decryption key is stored somewhere in the trusted enclave.
If my memory serves me correctly, this feature was never marketed by AMD for these CPUs and was unstable.
The only mistake AMD potentially made here is not being transparent why it was disabled.
This sort of shenanigan is why it’s important to have a competitive market for CPUs.
it's exactly why we're not allowed a competitive market for CPUs
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.
> 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.
IP laws. You personally might be able to do this. But should you attempt to sell a device that makes it easy for anyone to do, you will get sued into oblivion.
There's a big difference.
> I am pretty sure there are entire YouTube channels dedicated to this.
There is: https://www.youtube.com/@Dr.Semiconductor
I think we are in the era we have so many CPU choices.
If it can be silently removed was it a security feature?
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?
Sneakily and silently removing a feature in a firmware revision is not acceptable, security or otherwise.
if anyone does it sneakily, there is alleged wrongdoing attached to it. I can imagine multiple scenarios like some well-known Israeli company "selling their software only to governments", paying quite amount of money for it, because they were unable to break this one.
> there is alleged wrongdoing attached to it
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).
> Apple cause batterygate with good intentions but sneakily.
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?
If you ever had to use an iPhone that would just shut off randomly with like 30% battery "remaining", you'd probably be singing a different tune and appreciative your device became somewhat more usable with the changes.
I'd expect the battery charge estimation to be recalibrated to account for the reduced capacity, not the hardware being deliberately hobbled to hide it.
I heard the old batteries, when giving high current would depress voltage long enought to trigger the shutdown, plausibly long enough to mess up the processor if it didn't shut down, but could genuinely give a lower current for a long time, such that rounding the charge down to zero would be harmful. It's easy to argue it's better to keep the phone slower then just shut it down when it can't reliably go fast.
But it’s not a matter of total charge, but output, hence it shutting down even though there’s plenty of stored energy in the battery.
> Sneakily and silently removing a feature in a firmware revision is not acceptable
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?
Removing it required AMD's firmware code signing keys. If an attacker has those and some time they can do much worse.
To be honest it never worked great - many issues (mostly freezes) with VFIO, NVidia drivers, amdgpu...
I would be fine with this if it meant CPUs became slightly cheaper, but we know that's not going to happen.
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...
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, enterprises are paying the big bucks for more than just these standalone features.
Reminds me of subscription heated seats in bmw cars. The hardware is already there, you paid for it and you can’t use it unless you give the automaker a revenue stream on top of the tens of thousands you already paid for the car.
Same with some old IBM hardware: two CPUs were installed in each box, but if you bought only 1 CPU server other one is disabled via firmware.
I think intel tried to offer GPU virtualisation with their consumer offerings but not sure what happened to that.
Yes, I think Intel did offer that, but I recall hearing their software wasn't very good.
crazy amd was the leader for secure memory encryption for consumer while no competitor provided it
Hint: NSA said no.
Why did the NSA wait 9 years to say no & why does that explain the coincidence of the feature being supported in the PRO variants of the same CPU, which just happen to cost more?
If the NSA wanted to say no they'd just ask for some kind of back door and call it a day.
NSA added disabling switch in the first place
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.
No clear difference beyond the scaling to 6x the memory channels, 24x the memory capacity, 12x the core count, 6x the PCIe lanes, and ability to double (or nearly double) these with a 2nd socket. There are also a few features, like per VM memory encryption, which have only ever been on Epyc (and "real" Epyc, not just any Epyc branded consumer platforms).
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.
What’s the different between these two:
Consumer:
https://www.amd.com/en/products/processors/desktops/ryzen/90...
EPYC variant:
https://www.amd.com/en/products/processors/server/epyc/4005-...
The Epyc 4585PX falls into the `(and "real" Epyc, not just any Epyc branded consumer platforms)` note. I.e. it is the same CPU as the AMD Ryzen 9 PRO 9965X3D, branded differently because it is certified against "server" branded motherboards instead of "standard" PC motherboards (same socket/chipset though, outside firmware validation the two are swappable). It carries none of the actual Epyc feature sets, just the PRO features, and the feature differences are therefore the same as any other PRO CPU.
No vendor should be able to do this remotely at all. Irrespective of security vulnerabilities present or not.
The github issue that never made it in this news: https://github.com/AMDESE/AMDSEV/issues/292
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 this serious about security, you should be manufacturing your own hardware.
If you're this serious about security, then manufacturing your own hardware isn't good enough, you need to create your own big bang to seed your own planet to source your own helium to be used in the production of your own ICs.
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?
I wouldn't trust myself to manufacture my own hardware.
If you're serious about privsec you should use GrapheneOS.
Then learn? Otherwise, you have to trust those that do.
Everyone jumping up about "enshitification". I tried to enable this feature on QEMU and it broke my VMs because the secure memory system was board-line hopelessly broken/non-functional.
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.
So it seems that the Ryzen PRO in my HP EliteBook is not affected.
"silently"
Everything is done silently and quietly nowadays.
Because they're words LLMs like to use. But in this instance it seems like the word a human would pick, too.
"AMD, with nary antecedent aforenotice, has elected to excise"...
I'm curious about Denuvo's opinion on that.
Why would Denuvo have an opinion?
denuvo is dead in the water right now, anyways
AMD's memory encryption is completely transparent and irrelevant to the OS and its applications hence the transparent in the name.
Any idea what's happening? This sounds _bad_.
Market segmentation.
How does market segmentation work if you refuse to clarify which chips have the feature and which chips don't?
I would also like to know. Surely some people here have at least second-hand knowledge, and silence can sometimes be deafening.
It's not bad at all. Long story short, this feature prevented people stealing your ram stick off of your machine, super-freezing it and quickly moving it to their machine before the charge runs out and read off whatever bits are still left intact.
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.
> To be fair to AMD, there is no clear indication that the company ever publicly advertised TSME as a consumer Ryzen feature.
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.
How can manufacturers simultaneously have exceptional control over flags and not enough control to know what flags are enabled on their shipping products?
They either have that control or they don't.
AMD, historically, has taken a "we don't test enterprise features on consumer SKUs, but we don't fuse them off if you really want to qualify it or let them try it" approach to e.g. ECC on consumer chips with Zen.
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.
They always had control. Awareness is a different thing. You could just as well ask "if you've written every line of code, why did you write that bug?".
I'm trying to progress the discussion past "we don't know if it was intentional". We know it was intentional. What was the intention of having it on before and what is the intention of turning it off?
You choose every piece of food you eat, how do you not know all the macros?
This analogy holds true if I invented every molecule in my food.
AMD has limited control over what motherboard manufacturers do. And there have been plenty of examples demonstrating motherboard vendors don't fully understand what they are doing. Stuff like shipping builds with example/placeholder keys, ridiculous voltage settings which destroy the cpu. Even if motherboard vendors don't have full control to configure to freely change every flag, they probably have access to some kind of debug/development firmware which has a lot more features enabled than what you would have in consumer builds.
> I would guess that the number of owners of consumer chips who also relied on them for encryption is exceedingly small.
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.
In that case I would expect them to try and work something out with AMD directly instead of building a company on undocumented features.
Just dont upgrade the Mainboard firmware then
To be fair same can't be said of ECC, even though ECC should be basic feature out of the box.
> A feature that was possibly accidentally enabled on consumer chips is now being disabled.
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.
AMD is busy learning all the wrong lessons from Intel.
I wonder what the additional power draw of these features would be. Parenthetically, I wonder often about the energy impact of all these HTTPS localhost links, and is there a point where defense-in-depth has to give way to other concerns?
But yeah 95% of the consumer market don't care about this and it's only adding unnecessary costs
Consumers were always capable of disabling it themselves if they didn't need it. The performance impact seems to be ~3% on average, impact on power consumption is probably similar or less since any extra delay idling can destroy performance while not having as big impact on power consumption. https://www.phoronix.com/review/amd-memory-guard-ram-encrypt...
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.
Another example on how AMD is hardly the good guys.
It's a shame there is no software-based memory encryption included in the linux kernel. Especially cloud providers can easily snoop all your keys and you have zero recourse.
There was a patch called Tresor that did this, but I don't think it was updated for a long time.
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).
Realistically as an European my threat are backdoored components from Epstein's colleagues at five eyes which are used for mass-surveillance of VMs at European hosters such as Hetzner. And every time you add a configuration option like memory encryption it makes their drive-by mass surveillance a tiny bit more difficult and hopefully easier to detect for the sysadmins at Hetzner.
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.
> 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.
Interesting insight. Any reason why the key can't be kept exclusively in the secure enclave / trusted platform module / crypto coprocessor?
I can think of a few reasons:
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 :)
> 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.
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".
In a cloud provider situation there is no pure software solution to this, the hypervisor can always dump your memory pages / register states
It's one piece of a proper defense-in-depth approach. Europe needs to hope for the best but prepare for the worst.
Software-based memory encryption would be horrendously slow, and realistically you'd still need to have the key in memory.
This will be re-added in a few years. The current flip-flop is just enshittification.
It is sad that once again we will be exposed to more criminals trying to steal our data. Memory encryption not only allows to secure memory from physical "cold RAM", but also prevents loss of encryption keys as it hides the content during transfer.
For what it's worth, RAM encryption belongs to professional SKUs. It's the right business decision that should have been made from from the very beginning.
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.
I disagree, I play a lot around with enterprise stuff. Its insane that I need to buy enterprise grade hardware that costs 1000x more for lab/experimentation/learning. My only alternative is to wait a few years, and get it from Ebay.
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.
how do you know what threats I face? how do you know what threats journalists and whistleblowers face?
this is approximately the same discussion as with ECC RAM: the benefits vastly outweigh the slight performance loss and die area increases.
ECC passively benefits everyone, even people who don't know what it is or why it's useful. Anyone can be a victim of random bit flips, it's not a targeted threat.
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.
Memory encryption can help mitigate much lower level attacks such as row hammer, these attacks get patched even average consumer devices.
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.
This is an absurd take since the referenced chips in the article are all desktop parts, and the power usage is dwarfed by any “modern” (within the last five years) GPU.
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.