Re: [PATCHv3 0/5] x86: Enumerate TME and PCONFIG, add MKTME_KEY_PROG helper

[Kirill A. Shutemov]

On Sun, Feb 11, 2018 at 08:02:41PM +0100, Ingo Molnar wrote:
> 
> * Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> wrote:
> 
> > Multikey Total Memory Encryption (MKTME)[1] is a technology that allows
> > transparent memory encryption in upcoming Intel platforms.
> >
> > MKTME is built on top of TME. TME allows encryption of the entirety of
> > system memory using a single key. MKTME allows to have multiple encryption
> > domains, each having own key -- different memory pages can be encrypted
> > with different keys.
> > 
> > The patchset does some ground work for MKTME enabling:
> >   - Adds two new cpufeatures: TME and PCONFIG;
> >   - Detects if BIOS enabled TME and MKTME;
> >   - Enumerates what PCONFIG targets are supported;
> >   - Provides helper to program encryption keys into CPU;
> > 
> > As part of TME enumeration we check out how many bits from physical address
> > are claimed for encryption key ID. This may be critical as we or guest VM
> > must not use these bits for physical address.
> 
> So how will the 'full' patchset look like, roughly - is there a tree or diffstat 
> we could take a look at perhaps?

I don't have anything to show beyond this yet. I'll post as soon I have it
ready.

This patchset includes only things that are close to hardware and unlikely
to change substantially by the next steps.

> I'm also wondering how 'TME' compares to AMD's SME (Secure Memory Encryption) and 
> SEV features. SME required a number of low level boot code changes - I'm wondering 
> how much commonality there can be achieved with Intel's TME so that we don't end 
> up with two sets of interfaces.

Unlike AMD SME, Intel TME doesn't really requires enabling on kernel side.

It's job of BIOS to get it enabled and by time kernel has control all
memory it has access too is encrypted with the single TME key. BIOS
exclude some of its memory for encryption to work properly.

What requires enabling is MKTME. As with TME, it gets enabled by BIOS: it
reserves a number of upper bits from physical address to indicate KeyID.

This means we don't need to change anything during early boot. MKTME is
targeted to userspace memory: typically to protect one VM from another.

Of course we can choose to use MKTME for kernel hardening and it may
require changes during early boot, that's not part of my initial enabling
plan.

Key design points of Intel MKTME:

 - Initial HW implementation would support upto 63 keys (plus one default
   TME key). But the number of keys may be as low as 3, depending to SKU
   and BIOS settings

 - To access encrypted memory you need to use mapping with proper KeyID
   int the page table entry. KeyID is encoded in upper bits of PFN in page
   table entry.

   This means we cannot use direct map to access encrypted memory from
   kernel side. My idea is to re-use kmap() interface to get proper
   temporary mapping on kernel side.

 - CPU does not enforce coherency between mappings of the same physical
   page with different KeyIDs or encryption keys. We wound need to take
   care about flushing cache on allocation of encrypted page and on
   returning it back to free pool.

 - For managing keys, there's MKTME_KEY_PROGRAM leaf of the new PCONFIG
   (platform configuration) instruction. It allows load and clear keys
   associated with a KeyID. You can also ask CPU to generate a key for
   you or disable memory encryption when a KeyID is used.

If you have any questions I would be glad to answer.

-- 
 Kirill A. Shutemov