> 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.
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 useful, but it is prudent to also consider how the technology might be used as a weapon.
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.
edit: Forgot to mention: the single-key variation (TME) can provide a lot of the user-focused benefits, without the DRM proliferation risk.
> I don’t even see how a future MKTME v2 would be useful for DRM.
Intel already tried that with SGX. (Intel's documentation for SGX was all about creating a "Trusted Computing" environment, using the old Palladium/NGSCB DRM-sense of "trusted".
Yep. Full memory encryption formed the basis of the Xbox360's security, and other than one exploit that was patched pretty quickly, it needed a reset glitching attack to add unsigned code execution.
TME doesn't help much against local attackers, the memory controller isn't smart enough for that (yet), especially because the hypervisor still controls the keys.
It does however help to mitigate a number of attacks such as freezing memory to extract encryption keys and similar.
>> 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.
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?
Yeah, it's done at the memory controller level. No the caches won't be encrypted, but it wouldn't make sense to; any threat model that says L* caches can be read by an adversary should also allow the register file itself to be read, and that's going to contain unencrypted data (after all, you have to decrypt the data at _some_ point).
I do wonder, though, whether the memory remains protected against adversaries who can put rogue devices on the PCIe or UPI buses; it seems that these would be able to get decrypted data.
>I do wonder, though, whether the memory remains protected against adversaries who can put rogue devices on the PCIe or UPI buses; it seems that these would be able to get decrypted data.
Some NICs are able to dump data directly into the (L3) cache (DDIO on Intel), so either the L3 will have to be encrypted or the IOMMU needs to contain the crypto functionality.
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.
Apparently not because of what is said above about caches being unencrypted.
Past Intel architecture allows two threads to share a physical core in such a way as the cached data of the first thread may be probed with a timing attack to reveal confidential data.
Readit News
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 useful, but it is prudent to also consider how the technology might be used as a weapon.
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.
edit: Forgot to mention: the single-key variation (TME) can provide a lot of the user-focused benefits, without the DRM proliferation risk.
No it’s not. With MKTME, the kernel can read all memory, ptrace still works, etc. I don’t even see how a future MKTME v2 would be useful for DRM.
That's great, iff you have root-level access.
> I don’t even see how a future MKTME v2 would be useful for DRM.
Intel already tried that with SGX. (Intel's documentation for SGX was all about creating a "Trusted Computing" environment, using the old Palladium/NGSCB DRM-sense of "trusted".
It does however help to mitigate a number of attacks such as freezing memory to extract encryption keys and similar.
Deleted Comment
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.
How do you fix the "untrustworthy virtualization" problem then?
Does the spec say that the encryption be authenticated? If so, where are the MACs stored?
I do wonder, though, whether the memory remains protected against adversaries who can put rogue devices on the PCIe or UPI buses; it seems that these would be able to get decrypted data.
is that an issue when you have IOMMU?
Past Intel architecture allows two threads to share a physical core in such a way as the cached data of the first thread may be probed with a timing attack to reveal confidential data.