[RFC v2 10/13] keys/mktme: Add the MKTME Key Service type for memory encryption
Dave Hansen
dave.hansen at intel.com
Thu Dec 6 15:11:21 UTC 2018
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).
More information about the Linux-security-module-archive
mailing list