Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD silently removes memory encryption from consumer Ryzen CPUs

tomshardware.com

Post reply on HN
Print view View original

181–190 of 225 posts

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#181

Post by MostlyStable »

hgoel wrote: post #62

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.

I'm ok with a version of this as a concept. The version being when a feature is technically present in every SKU, but requires an extra purchase to unlock. A reply to you specifically mentioned subscriptions, which I very much do not like (except in cases where the feature requires ongoing costs), but there are many cases where having every version contain the feature, but requiring a purchase to unlock it is pro-consumer, and is a win-win-win (or at wist a win-win-draw). It can, under the right circumstances, allow the product to be available for a cheaper cost than it would otherwise be. So people who are willing to pay for it are better off, people who aren't willing to pay for maintain the option to change their mind for a nominal fee, and the company probably makes slightly more profit.

All that being said, in my opinion, it needs to come with several features:

1. no subscriptions for something that is just a one time unlock 2. It needs to be legal and protected for customers to figure out how to unlock it on their own without purchasing the unlock.

I haven't thought enough to have a strong opinion on the exact situation you describe (where it is present and an unlock isn't available at any fee), other than to say I'd still argue strongly that customers figuring out how to unlock it on their own should be legally protected.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#182

Post by teravor »

there is a MemoryOverwriteRequestControl efivar which I believe is set on by default in linux (need TPM enabled in bios) which will wipe memory on reboot.

should also set the MemoryOverwriteRequestControlLock (MorLock v1/v2) if you don't want it ever changed (on 'clean' reboot MOR is usually unset to facilitate a faster boot).

there is still the problem of actually triggering the reboot.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#183

Post by dark-star »

throw0101c wrote: post #93
DanielHB wrote: post #41

Earlier quoted context omitted.

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…

Tangentially related: https://www.youtube.com/watch?v=6uhO1SNJRMQ

Highspeed Highway Halo

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#184

Post by zorgmonkey »

pbmonster wrote: post #121
matja wrote: post #72

Earlier quoted context omitted.

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 shipp…

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

I don't know exactly how long loading value from a TPM takes, but my gut says it would be much too long to do it on task switch. Almost certainly fine for waking up from suspend though. Also the problem that physical TPMs communicate with the CPU over plaintext and TPMs in general, including fTPMs, have had notable vulnerabilities.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#185

Post by OGWhales »

blacklion wrote: post #78
loloquwowndueo wrote: post #66

Earlier quoted context omitted.

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.

Oh, they still do that with their new hardware. The machine comes with x amount of processor cores, but you can't use any of them without paying. How much you pay depends on the "MSUs" you agreed to, MSU being a proprietary measurement system by IBM.

Other software you run is billed relative to your MSU tier. So, if you run z/OS then your cost will be higher if your machine has more MSUs. A weird quirk of this is that there is thing called "IFLs" (Integrated Facility for Linux) which, when I when I first heard of them, I thought was a separate processor designed for for linux. However, it is not. It is actually the same as the regular processors that run z/OS etc, the difference is that is is licensed exclusively for running Linux (or like z/VM to run linux counts too). The reason for this is to enable shops that want to run linux and needed extra horsepower to do so, but didn't want their z/OS bills to go up because they purchased more MSUs. So, despite buying more of the processor capacity within the mainframe, it doesn't count towards the "MSU" number that impacts the cost of various software because you are using with one type of software vs another type of software.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#186

Post by 15155 »

fc417fc802 wrote: post #166
bob1029 wrote: post #96

Earlier quoted context omitted.

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

I think it's less any regulation and more the lack of products to facilitate it. The guys rolling their own from scratch on youtube weren't anywhere near 300 nm last I checked.

There are plenty of products to facilitate small-scale semiconductor manufacture: university nanofabs all over the world have them.

You can, too, without much/any paperwork... if you have the funds.

Re: AMD silently removes memory encryption from consumer Ryzen CPUs

#189

Post by 15155 »

akimbostrawman wrote: post #101
bakugo wrote: post #31

Earlier quoted context omitted.

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 extre…

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.

So can scrambling - which is not encryption.
Post reply on HN