Re: x86/sgx: uapi change proposal

[Sean Christopherson]

On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> On Tue, Jan 8, 2019 at 2:09 PM Sean Christopherson
> <sean.j.christopherson@xxxxxxxxx> wrote:
> >
> > Cleaner in the sense that it's faster to get basic support up and running
> > since there are fewer touchpoints, but there are long term ramifications
> > to cramming EPC management in KVM.
> >
> > And at this point I'm not stating any absolutes, e.g. how EPC will be
> > handled by KVM.  What I'm pushing for is to not eliminate the possibility
> > of having the SGX subsystem own all EPC management, e.g. don't tie
> > /dev/sgx to a single enclave.
> 
> I haven't gone and re-read all the relevant SDM bits, so I'll just
> ask: what, if anything, are the actual semantics of mapping "raw EPC"
> like this?  You can't actually do anything with the mapping from user
> mode unless you actually get an enclave created and initialized in it
> and have it mapped at the correct linear address, right?  I still
> think you have the right idea, but it is a bit unusual.

Correct, the EPC is inaccessible until a range is "mapped" with ECREATE.
But I'd argue that it's not unusual, just different.  And really it's not
all that different than userspace mmap'ing /dev/sgx/enclave prior to
ioctl(ENCLAVE_CREATE).  In that case, userspace can still (attempt to)
access the "raw" EPC, i.e. generate a #PF, the kernel/driver just happens
to consider any faulting EPC address without an associated enclave as
illegal, e.g. signals SIGBUS.

The /dev/sgx/epc case simply has different semantics for moving pages in
and out of the EPC, i.e. different fault and eviction semantics.  Yes,
this allows the guest kernel to directly access the "raw" EPC, but that's
conceptually in line with hardware where priveleged software can directly
"access" the EPC (or rather, the abort page for all intents and purposes).
I.e. it's an argument for requiring certain privileges to open /dev/sgx/epc,
but IMO it's not unusual.

Maybe /dev/sgx/epc is a poor name and is causing confusion, e.g.
/dev/sgx/virtualmachine might be more appropriate.

> I do think it makes sense to have QEMU delegate the various ENCLS
> operations (especially EINIT) to the regular SGX interface, which will
> mean that VM guests will have exactly the same access controls applied
> as regular user programs, which is probably what we want.

To what end?  Except for EINIT, none of the ENCLS leafs are interesting
from a permissions perspective.  Trapping and re-executing ENCLS leafs
is painful, e.g. most leafs have multiple virtual addresses that need to
be translated.  And routing everything through the regular interface
would make SGX even slower than it already is, e.g. every ENCLS would
take an additional ~900 cycles just to handle the VM-Exit, and that's
not accounting for any additional overhead in the SGX code, e.g. using
the regular interface would mean superfluous locks, etc...

The only benefit is that it would theoretically allow oversubscribing
guest EPC without hardware support, but that would require a lot of code
to do the necessary SECS tracking and refcounting.

> If so,
> there will need to be a way to get INITTOKEN privilege for the purpose
> of running non-Linux OSes in the VM, which isn't the end of the world.

Couldn't we require the same privilege/capability for VMs and and EINIT
tokens?  I.e. /dev/sgx/virtualmachine can only be opened by a user that
can also generate tokens.

> We might still want the actual ioctl to do EINIT using an actual
> explicit token to be somehow restricted in a way that strongly
> discourages its use by anything other than a hypervisor.  Or I suppose
> we could just straight-up ignore the guest-provided init token.
>
> P.S. Is Intel ever going to consider a way to make guests get their
> own set of keys that are different from the host's keys and other
> guests' keys?