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

[Sakkinen, Jarkko]

On Thu, 2018-12-06 at 07:11 -0800, Dave Hansen wrote:
> On 12/6/18 12:51 AM, Sakkinen, Jarkko wrote:
> > On Mon, 2018-12-03 at 23:39 -0800, Alison Schofield wrote:
> > > 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