Live data from Hacker News

AMD silently removes memory encryption from consumer Ryzen CPUs

tomshardware.com

51–60 of 225 posts

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#51

Earlier quoted context omitted.

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.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#52
post #45
post #33

Earlier quoted context omitted.

> 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.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#53
post #2

Any idea what's happening? This sounds _bad_.

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.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#54
post #12

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.

Many many people use consumer CPUs for gaming servers.

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?

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#55

Earlier quoted context omitted.

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.

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.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#57
post #43
post #30

Earlier quoted context omitted.

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…

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.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#58
post #52
post #45

Earlier quoted context omitted.

> 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.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#59
post #43
post #30

Earlier quoted context omitted.

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…

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).
Post reply on HN