> 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&
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.
https://github.com/amd/firmware_binaries/blob/main/cezanne/P...
AFAICT the situation here is, it should have never been enabled for these consumer parts in the first place.
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.
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.
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.
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.
The market segmentation arguments don't really work either, enterprises are paying the big bucks for more than just these standalone features.
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.
SR-IOV ("true" GPU partitioning) is targeted at the Arc Pro/DC GPUs only, not the desktop variants.
That leaves Intel in the same boat as the others these days: you can either pass the whole GPU through or buy a non-consumer variant for proper hardware virtualization (or try to hack it).
My reasoning there is if you used an encrypted drive, the decryption key you type when booting up would be stored in memory for the duration of that boot.
This seems alarming because it means if someone broke into your living quarters they can bypass all forms of disk encryption if your machine was on and locked. Encrypting your disks seems like a reasonable thing to want to do with consumer grade hardware.
It causes many stability issues, as to my experience.
The attack is sophisticated, Mr.Nobody, generally, should not worry about expensive cryogenic attacks - three letter guys would extract your key with a wrench.
I mean the change is bad - it undermines already damaged trust, but the "average Joe" is extremely unlikely to be affected directly.
There are many much cheaper ways to force you to give up your keys.
In my experience it very much does not, ram instability with this feature indicates a hardware issue same as with ECC.
>Mr.Nobody, generally, should not worry about expensive cryogenic attacks - three letter guys would extract your key with a wrench.
This is disingenuous framing. There exist valid threat models for average people between thieves and three letter agencies. Police forces and organized crime have been known to use ram freezing, the former is not known for wrench attacks. That scenario is only good for hand waving real concerns anyways.
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-...
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).
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.
Interesting insight. Any reason why the key can't be kept exclusively in the secure enclave / trusted platform module / crypto coprocessor?
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?
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?
Everything is done silently and quietly nowadays.
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.
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.
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.
If the NSA wanted to say no they'd just ask for some kind of back door and call it a day.
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?
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.
Then AMD created their EPYC variants, and it wasn’t clear what the difference was between the consumer & Epyc models.
Like the article hits spot on right at the start, it has nothing to do with needing to differentiate Epyc somehow and everything to with differentiating the PRO versions of the consumer CPUs:
> was suddenly no longer available on AMD CPUs outside the company's Pro lineup
The PRO variants are just the standard consumer CPU sold at a $ premium for enterprise targets. They have remote management firmware enabled, get longer firmware and support lifecycles, FIPS certification, and, now, memory encryption over the consumer branded version of the same CPU.
Consumer:
https://www.amd.com/en/products/processors/desktops/ryzen/90...
EPYC variant:
https://www.amd.com/en/products/processors/server/epyc/4005-...
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.
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...
I wouldn't be surprised if lower hardware prices and weaker demand for everything are more likely to lead to more feature rich products to encourage sales, and higher hardware prices hurting sales volume leads to a natural/expected contraction in feature availability to compensate for lower sales.
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.
Too many people downplaying this as a simple business decision from AMDs side but the response here is what really makes this a story.
Where there's smoke, there's fire.
This has implications beyond simply securing against physical access attacks, but also protects against rowhammer and its ilk.
Between this and their recent botched software update verification I'm getting a little wary of AMD.
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.
