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