Rendered at 12:34:33 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
thg 3 hours ago [-]
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.
DanielHB 2 hours ago [-]
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.
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.
close04 3 hours ago [-]
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.
thg 2 hours ago [-]
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.
kubik369 2 hours ago [-]
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).
close04 29 minutes ago [-]
> 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.
cwillu 2 hours ago [-]
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.
himata4113 2 hours ago [-]
Many many people use consumer CPUs for gaming servers.
embedding-shape 2 hours ago [-]
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?
nemomarx 2 hours ago [-]
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.
embedding-shape 2 hours ago [-]
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.
ChocolateGod 32 minutes ago [-]
I can't even think of what benefit memory encryption has for gaming servers?
endgame 49 minutes ago [-]
Yes.
porridgeraisin 2 hours ago [-]
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?
rolandog 1 hours ago [-]
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.
ChocolateGod 37 minutes ago [-]
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.
pluralmonad 6 minutes ago [-]
Why call out FUD when you only have more/different uncertainty to offer?
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.
shanoaice 1 hours ago [-]
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.
pshirshov 1 hours ago [-]
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.
deno 49 minutes ago [-]
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, so this feature is still useful against some adversaries.
pshirshov 28 minutes ago [-]
Well, I live in Ireland but not sure what you refer to.
Something being illegal does not imply it doesn't happen though.
>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.
pshirshov 25 minutes ago [-]
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.
inigyou 1 hours ago [-]
If they have liquid nitrogen and a memory dumping boot disk, or a memory bus interceptor.
beAbU 11 minutes ago [-]
Is this still a viable attack in 2026?
inigyou 8 minutes ago [-]
if you have liquid nitrogen and a memory dumping boot disk, or a memory bus interceptor
Integer 3 hours ago [-]
I had this enabled as it protects against RAMbleed/ECC errors, so it's not limited to physical attacks.
riobard 2 hours ago [-]
Are you sure? I thought it's just AES without any authentication.
bonzini 2 hours ago [-]
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.
Karliss 49 minutes ago [-]
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.
crest 1 hours ago [-]
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.
nish__ 7 minutes ago [-]
If you're this serious about security, you should be manufacturing your own hardware.
ZiiS 4 hours ago [-]
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?
mike_hock 3 hours ago [-]
Sneakily and silently removing a feature in a firmware revision is not acceptable, security or otherwise.
p0w3n3d 3 hours ago [-]
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.
close04 2 hours ago [-]
> 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).
zx8080 2 hours ago [-]
> 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?
russelg 2 hours ago [-]
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.
cwillu 2 hours ago [-]
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.
emiliobumachar 43 minutes ago [-]
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.
techpression 57 minutes ago [-]
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.
close04 34 minutes ago [-]
Even tech minded people get this wrong. The capacity is irrelevant. The battery's ability to still deliver current spikes and not have a huge voltage drop is what holds them back. You can have usable capacity and be limited to idle tasks because any CPU spike causes the battery to cut off and the phone to reset.
embedding-shape 2 hours ago [-]
> 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?
crest 1 hours ago [-]
Removing it required AMD's firmware code signing keys. If an attacker has those and some time they can do much worse.
nickdothutton 1 hours ago [-]
This sort of shenanigan is why it’s important to have a competitive market for CPUs.
functionmouse 1 hours ago [-]
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.
bob1029 30 minutes ago [-]
> 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.
hgoel 1 hours ago [-]
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.
loloquwowndueo 1 hours ago [-]
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.
blacklion 1 hours ago [-]
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.
alberth 36 minutes ago [-]
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.
zamadatix 6 minutes ago [-]
No clear difference beyond the 6x increase in memory channels, 24x memory capacity, 16x increase in core counts, 6x increase in PCIe lanes, and ability to double (or nearly double) most of these with a 2nd socket. There are also a few features, like per VM memory encryption, which have inly ever been on Epyc (and "real" Epyc, not just any Epyc branded platform).
Like the article hits spot on right st the start, it has nothing to do with Epyc 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 for enterprise support. They have remote management firmware enabled, get longer firmware and support lifecycles, FIPS certification, and now, more exclusively, memory encryption over the consumer version of the same consumer branded version of the CPU.
ChocolateGod 34 minutes ago [-]
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.
Elfener 3 hours ago [-]
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...
pshirshov 2 hours ago [-]
To be honest it never worked great - many issues (mostly freezes) with VFIO, NVidia drivers, amdgpu...
rekttrader 4 hours ago [-]
Hint: NSA said no.
zamadatix 2 minutes ago [-]
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.
NooneAtAll3 2 hours ago [-]
NSA added disabling switch in the first place
k__ 3 hours ago [-]
I'm curious about Denuvo's opinion on that.
Retr0id 57 minutes ago [-]
Why would Denuvo have an opinion?
nicman23 41 minutes ago [-]
denuvo is dead in the water right now, anyways
akimbostrawman 41 minutes ago [-]
AMD's memory encryption is completely transparent and irrelevant to the OS and its applications hence the transparent in the name.
sva_ 1 hours ago [-]
So it seems that the Ryzen PRO in my HP EliteBook is not affected.
SirFatty 54 minutes ago [-]
"silently"
Everything is done silently and quietly nowadays.
crest 1 hours ago [-]
AMD is busy learning all the wrong lessons from Intel.
Anounimus 40 minutes ago [-]
Anonymous
lompad 4 hours ago [-]
Any idea what's happening? This sounds _bad_.
voxadam 4 hours ago [-]
Market segmentation.
kijin 2 hours ago [-]
How does market segmentation work if you refuse to clarify which chips have the feature and which chips don't?
ykonstant 4 hours ago [-]
I would also like to know. Surely some people here have at least second-hand knowledge, and silence can sometimes be deafening.
porridgeraisin 2 hours ago [-]
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.
themafia 4 hours ago [-]
> 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.
willis936 4 hours ago [-]
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.
rincebrain 2 hours ago [-]
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.
lmz 4 hours ago [-]
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?".
willis936 2 hours ago [-]
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?
3 hours ago [-]
nikanj 3 hours ago [-]
You choose every piece of food you eat, how do you not know all the macros?
willis936 2 hours ago [-]
This analogy holds true if I invented every molecule in my food.
Karliss 2 hours ago [-]
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.
AussieWog93 2 hours ago [-]
> 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.
NekkoDroid 1 hours ago [-]
In that case I would expect them to try and work something out with AMD directly instead of building a company on undocumented features.
Azantys 1 hours ago [-]
Just dont upgrade the Mainboard firmware then
Ygg2 3 hours ago [-]
To be fair same can't be said of ECC, even though ECC should be basic feature out of the box.
vfclists 2 hours ago [-]
> 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.
bflesch 3 hours ago [-]
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.
matja 3 hours ago [-]
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).
pbmonster 3 hours ago [-]
> 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?
matja 1 hours ago [-]
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 :)
benjojo12 3 hours ago [-]
In a cloud provider situation there is no pure software solution to this, the hypervisor can always dump your memory pages / register states
rusk 2 hours ago [-]
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
Karliss 2 hours ago [-]
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.
pjmlp 3 hours ago [-]
Another example on how AMD is hardly the good guys.
shiiiit 3 hours ago [-]
This will be re-added in a few years. The current flip-flop is just enshittification.
miga 4 hours ago [-]
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.
garganzol 4 hours ago [-]
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.
olavgg 3 hours ago [-]
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.
baq 3 hours ago [-]
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.
bakugo 3 hours ago [-]
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.
akimbostrawman 23 minutes ago [-]
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 reasonable to do so.
rubyn00bie 3 hours ago [-]
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.
bflesch 3 hours ago [-]
Weird, maybe you should start posting about the Epstein stuff and you'll quickly learn about your threat situation.
https://youtu.be/5etwHVarNgI?t=256
> 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)
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.
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.
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.
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.
Something being illegal does not imply it doesn't happen though.
and recent Supreme Court decision:
https://www.algoodbody.com/insights-publications/password-pr...
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.
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.
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?
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.
The market segmentation arguments don't really work either, enterprises are paying the big bucks for more than just these standalone features.
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 st the start, it has nothing to do with Epyc 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 for enterprise support. They have remote management firmware enabled, get longer firmware and support lifecycles, FIPS certification, and now, more exclusively, memory encryption over the consumer version of the same consumer branded version of the CPU.
The only mistake AMD potentially made here is not being transparent why it was disabled.
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...
If the NSA wanted to say no they'd just ask for some kind of back door and call it a day.
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 :)
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.
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 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.
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 reasonable to do so.
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.