* Kirill A. Shutemov <kir...@shutemov.name> wrote:
> On Sun, Feb 11, 2018 at 08:02:41PM +0100, Ingo Molnar wrote:
> >
> > * Kirill A. Shutemov <kirill.shute...@linux.intel.com> 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.
Ok.
> > 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.
Ok, this sounds pretty flexible at first glance - thanks for the summary!
Ingo
