> Total Memory Encryption (TME) ... uses a single, CPU-generated key for all of memory; users can control the usage of TME in the boot-level firmware. A new standard ... MKTME ... supports different encryption settings ... at the page level, and more keys. Different keys can be used at the same time for different memory regions.<p>While using multiple keys has legitimate advantages for the user, it's also a step towards unbreakable DRM and other malware. It's easy to think about how a new technology is <i>useful</i>, but it is prudent to also consider how the technology might be used as a <i>weapon</i>.<p>Memory encryption has obvious niche uses, but seems slightly outside the common threat model for most people (users). The more likely use-case (for the average user) is probably user-hostile: DRM, "Denuvo"-style tamper resistance.<p>edit: Forgot to mention: the single-key variation (TME) can provide a lot of the user-focused benefits, without the DRM proliferation risk.
>> In a virtualized environment, if attackers can find a way to read memory from neighbor virtual machines, they can access the data from those machines.<p>I would not advocate memory encryption as a defense against this kind of attack. It's added complexity to fix a different problem (untrustworthy virtualization). OTOH it is useful to protect against physical access at the hardware level - and that's not really a common concern but is valid is some cases.
Does this mitigate any kind of rowhammer attacks? The kernel will be managing the keys, but if normal programs don't have access to them they would be unable to predict the actual bytes written, which I think is necessary for rowhammer.
Correct me if I got this wrong, but what we are talking about is basically having a hardware encryption processor and tmp-like module within the cpu chip itself, sitting between the memory controller and the cpu. Does that also cover the L caches?
I don't really understand the threat model in which this provides a real security benefit. If someone can inspect the contents of memory, can't they also recover the encryption key somehow?
All the discussion ITT so far has been about the concept or hardware implementation of full-memory encryption. I'm wondering if anyone has thoughts about the proposed API.