A proposed API for full-memory encryption(lwn.net)
lwn.net
A proposed API for full-memory encryption
https://lwn.net/Articles/776688/
41 comments
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?
What are the performance implications with memory encryption?
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.
What is the encryption algorithm Intel is planning to implement? I can’t seem to find any references to it.
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.
>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?
is that an issue when you have IOMMU?
http://research.cs.wisc.edu/multifacet/papers/micro15_border...
I think this paper presents an interesting overview of how to mitigate a subset of hw-related attack vectors. Seems really relevant.
I think this paper presents an interesting overview of how to mitigate a subset of hw-related attack vectors. Seems really relevant.
I don't believe Intel (whose implementation of encryption this targets) have an IOMMU for PCIe. For UPI (or whatever inter-socket protocol is going on), it wouldn't make sense to have an IOMMU since cores need permission to do arbitrary reads anyway.
Intel has an IOMMU for PCIe. And DMA sees cleartext with (MK)TME.
There are hardware based cheats for CSGO. It’s a PCI card with some custom CPU/FPGA on it that scans and changes values inside the memory of the game.
When I read the title I hoped it would protect against that too, but no such luck then, I guess?
When I read the title I hoped it would protect against that too, but no such luck then, I guess?
TBH if you have to resort to bus-based cheating in a game then I'd say it counts as a win for the anti-cheat software.
There are plenty of cheats that are seemingly impossible to detect. I play Team Fortress 2 and there's at least one cheat there that, from what I've read, uses code that's unique to each instance used by a cheater. VAC seems to scan for code signatures so it doesn't detect it.
This hardware cheat makes it even harder to detect since it reads and writes directly to main memory using DMA. No drivers or software needed at all. All you possibly could detect is the PCI-ID(which can be changed) and possibly the DMA if there's an IOMMU.
https://blog.esea.net/esea-hardware-cheats/
This hardware cheat makes it even harder to detect since it reads and writes directly to main memory using DMA. No drivers or software needed at all. All you possibly could detect is the PCI-ID(which can be changed) and possibly the DMA if there's an IOMMU.
https://blog.esea.net/esea-hardware-cheats/
> And DMA sees cleartext with (MK)TME.
Could you please translate this into non-expert language? Does it mean DMA granted devices can break IOMMU separation?
Could you please translate this into non-expert language? Does it mean DMA granted devices can break IOMMU separation?
No, I mean that, if the IOMMU is off or if it allows access to an address, then MKTME will treat that access exactly as though it was a normal access from the CPU. So, if the device selects the right key (the key uses some otherwise unused physical address bits), then the device will access the decrypted data.
VT-d is an IOMMU for PCIe.
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.
Or maybe the kernel would have to except some memory for MMIO from being encrypted. That way the PCIe bus gets access to the memory without needing the keys but also can't read what it shouldn't.
AIUI Intel TME sits in the memory controller, same for MKTME. Therefore memory protection as usual protects access, and any read/write requests made to the IMC will have it use the correct keys for en/decryption. The IMC doesn't care/tell where those requests came from.
That's the way the 360 did it, total memory encryption, but practically DMA buffers were unencrypted.
I guess this would help with Meltdown/Spectre type bugs.
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.
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.
> 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.
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.
> While using multiple keys has legitimate advantages for the user, it's also a step towards unbreakable DRM and other malware.
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.
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.
> the kernel can read all memory
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".
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".
> That's great, iff you have root-level access.
And if you don’t have root access, then you can’t read other users’ memory. The MMU must be an evil scheme for DRM!
And if you don’t have root access, then you can’t read other users’ memory. The MMU must be an evil scheme for DRM!
The difference is that SGX was explicitly designed to protect memory/execution from kernel access, and TME doesn’t have such a facility or any path I can see towards becoming one.
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.
It does however help to mitigate a number of attacks such as freezing memory to extract encryption keys and similar.
How much DRM today is broken because of attacks on in-the-clear memory? I didn't think that was a standard way to attack DRM.
[deleted]
>> 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.
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.
> It's added complexity to fix a different problem (untrustworthy virtualization).
How do you fix the "untrustworthy virtualization" problem then?
How do you fix the "untrustworthy virtualization" problem then?
Oh, that's easy. Just fix all the bugs.
Including bugs in the hardware itself, of course:)
(There's a reason why Spectre and Meltdown were a horror show for virtualization.)
(There's a reason why Spectre and Meltdown were a horror show for virtualization.)
Right, but do you have any actionable solutions for mere mortals?
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.
I would venture that it does. It’s much, much more likely that forced bit-flips via RH would break decryption vs cause some malicious code execution.
If the encryption has no authentication, an attacker could still conceivably flip individual bits, much like they can when attacking a stream cipher.
Does the spec say that the encryption be authenticated? If so, where are the MACs stored?
Does the spec say that the encryption be authenticated? If so, where are the MACs stored?
I don't think this proposal supports authenticated encryption, but if you're using ECC RAM, you could batch up groups of 8x72bit DDR lines, giving you 64 non-data bits: 10 bits for single error correction on a 576bit batch, and 54 bits for MAC. If your L3 uses 64-byte or larger cache lines, this is mostly free; you could also scale this up or down depending on how many MAC bits you want versus how large youre cache lines are.
Intel TME uses AES-XTS, which is less malleable[1] compared to say AES-CTR, which would provide no protection against rowhammer.
[1] This is a bad kind of security that's very difficult to reason about because it is unsound. This is a matter of "less worse, relatively speaking". The obviously superior and secure approach is to use AEAD, but that would be more difficult to integrate into the system.
[1] This is a bad kind of security that's very difficult to reason about because it is unsound. This is a matter of "less worse, relatively speaking". The obviously superior and secure approach is to use AEAD, but that would be more difficult to integrate into the system.