Hacker News Reader

Comment by eqvinox | Hacker News Reader

I really don't see the point of encrypting memory this way, with what boils down to a global key.

Anything breaking security of your OS kernel or some trusted process will still be able to steal all your data, since it's executing on the CPU with access to the keys.

Any attacker with physical access can still grab a hold of some PCIe or LPC port somewhere and try to convince your IOMMU to let it DMA out all memory. Or just manipulate the BIOS to install a permanent rootkit.

Why is this not using per-page or per-process keys, in some kind of secure storage? That'd actually add another barrier even if the kernel is already compromised. And the CPU does actually support this... but only for VMs with SEV, it seems. Would be nice to extend this.

View on HN

> I really don't see the point of encrypting memory this way, with what boils down to a global key.

SME was initially developed for game consoles[1], and was designed to protect security keys used for DRM against hardware probing. The feature makes sense in that environment, or any environment where the computer may realistically fall into the hands of an adversary (e.g., a laptop) while still running.

Plain SME on a server doesn't really make sense for DRAM unless your threat model needs to protect against extremely sophisticated attackers (although if there's no real performance hit, you may as well just enable it). However, it would be useful on a system with NVDIMMs.

[1] https://www.crn.com/news/components-peripherals/amd-s-xbox-p...

Can it protect against DMA access from malicious PCI devices (in case the IOMMU has to be disabled, e.g. for performance reasons)?

In transparent mode it will only protect against somebody pulling the Stick, in per page mode it will depend on the mode.

In this case, the adversaries are end users

> although if there's no real performance hit, you may as well just enable it

Even if it is no-cost performance wise, it still costs energy, which translates to heat and CO2.

> protect against extremely sophisticated attackers

I agree, and I'm very doubtful whether any attacker with this level of sophistication and access (i.e. physical to the DIMMs) won't have quite a few other venues of attack that are still viable.

This prevents an attacker from ripping out your RAM and freezing it so they can pull secrets from it, which isn’t really an “exploit” per se. I’m sure they have other mitigations for those kinds of things. Or at least I hope they have something in mind, since they didn’t seem to be hiring for security currently…

Is there known instances of this attack? For me it sounds like Sci-Fi.

It's routine: https://en.wikipedia.org/wiki/Cold_boot_attack

I don't know how often forensics teams bother freezing the memory; it's not always necessary.

It's routine in the lab. If you can get into a CloudFlare cage there may be much more powerful attacks than stealing DIMMs.

>I really don't see the point of encrypting memory this way

This is extremely useful for cloud providers that provide Virtual Private Servers.

How so?

If each resident VM is a(n attested) hardware enclave with its own memory encryption key (stored in a software-inaccessible register), a privilege escalation attack from one VM would not be able to yield the contents of the other VMs. The best an adversary could do is deny service to the other VMs, but that's always allowed by the threat model.

To my knowledge, VPSes are generally container'd these days, not VM'd, so SME/SEV doesn't actually work. But yes, this seems to be single-targeted at a specific VM threat.

(Add: another reason to extend this to per-process or per-page encryption, since that would work on containers too.)

That's the right idea. How do we allow per-process or per-page encryption of memory with hardware attested keys? Imagine if you can plug in your own key store from an HSM. This starts to really create some interesting defenses against very common security enterprise threat modeling.

> To my knowledge, VPSes are generally container'd these days

Not true. AWS is still largely on Xen, and most others are using KVM. Serverless (Lamdba) is a different story, but EC2 instances are largely Xen VM's, not containers.

Reply on news.ycombinator.com