21–30 of 225 posts
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 c…
Earlier quoted context omitted.
> 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 o…
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.
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.
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 c…
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.
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.
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.
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).
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.