
A proposed API for full-memory encryption - l2dy
https://lwn.net/Articles/776688/
======
pdkl95
> 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.

~~~
amluto
> 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.

~~~
pdkl95
> 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".

~~~
amluto
> 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!

------
phkahler
>> 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.

~~~
xyzzyz
> It's added complexity to fix a different problem (untrustworthy
> virtualization).

How do you fix the "untrustworthy virtualization" problem then?

~~~
tedunangst
Oh, that's easy. Just fix all the bugs.

~~~
yjftsjthsd-h
_Including_ bugs in the hardware itself, of course:)

(There's a reason why Spectre and Meltdown were a horror show for
virtualization.)

------
infogulch
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.

~~~
cobbzilla
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.

~~~
nemo1618
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?

~~~
a1369209993
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.

------
belorn
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?

~~~
dooglius
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.

~~~
gruez
>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?

~~~
dooglius
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.

~~~
amluto
Intel has an IOMMU for PCIe. And DMA sees cleartext with (MK)TME.

~~~
Flow
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?

~~~
blattimwind
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.

~~~
Flow
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/](https://blog.esea.net/esea-
hardware-cheats/)

------
swordswinger12
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?

------
the_arun
What are the performance implications with memory encryption?

------
smitherfield
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.

------
ape4
I guess this would help with Meltdown/Spectre type bugs.

~~~
SlipperySlope
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.

------
zatempat80
What is the encryption algorithm Intel is planning to implement? I can’t seem
to find any references to it.

