Thread (91 messages) 91 messages, 11 authors, 2018-12-13

Re: [RFC v2 10/13] keys/mktme: Add the MKTME Key Service type for memory encryption

From: Sakkinen, Jarkko <hidden>
Date: 2018-12-06 22:56:32
Also in: keyrings, linux-mm

On Thu, 2018-12-06 at 07:11 -0800, Dave Hansen wrote:
On 12/6/18 12:51 AM, Sakkinen, Jarkko wrote:
quoted
On Mon, 2018-12-03 at 23:39 -0800, Alison Schofield wrote:
quoted
MKTME (Multi-Key Total Memory Encryption) is a technology that allows
transparent memory encryption in upcoming Intel platforms. MKTME will
support mulitple encryption domains, each having their own key. The main
use case for the feature is virtual machine isolation. The API needs the
flexibility to work for a wide range of uses.
Some, maybe brutal, honesty (apologies)...

Have never really got the grip why either SME or TME would make
isolation any better. If you can break into hypervisor, you'll
have these tools availabe:
For systems using MKTME, the hypervisor is within the "trust boundary".
 From what I've read, it is a bit _more_ trusted than with AMD's scheme.

But, yes, if you can mount a successful arbitrary code execution attack
against the MKTME hypervisor, you can defeat MKTME's protections.  If
the kernel creates non-encrypted mappings of memory that's being
encrypted with MKTME, an arbitrary read primitive could also be a very
valuable in defeating MKTME's protections.  That's why Andy is proposing
doing something like eXclusive-Page-Frame-Ownership (google XPFO).
Thanks, I was not aware of XPFO but I found a nice ~2 page article about it:

https://lwn.net/Articles/700647/

I think the performance hit is the necessary price to pay (if you want
something more opaque than just the usual "military grade security"). At
minimum, it should be an opt-in feature.

/Jarkko
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help