Message-ID: <CALCETrW2wPq_umu6jNzCMvR6kphTZhcEody6ok64yyLWvfrvTg@mail.gmail.com>
Date:   Thu, 10 Jan 2019 13:34:44 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        "Huang, Kai" <kai.huang@...el.com>,
        Jethro Beekman <jethro@...tanix.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "x86@...nel.org" <x86@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        Josh Triplett <josh@...htriplett.org>,
        Haitao Huang <haitao.huang@...ux.intel.com>,
        "Dr . Greg Wettstein" <greg@...ellic.com>
Subject: Re: x86/sgx: uapi change proposal

>> On Jan 9, 2019, at 8:31 AM, Sean Christopherson <sean.j.christopherson@...el.com> wrote:
>>
>> 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@...el.com> 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...

Trapping EINIT is what I have in mind.

>
> 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.

Hmm, maybe.  Or we can use Jarkko’s securityfs attribute thingy.

Concretely, I think there are two things we care about:

First, if the host enforces some policy as to which enclaves can
launch, then it should apply the same policy to guests — otherwise KVM
lets programs do an end run around the policy. So, in the initial
incarnation of this, QEMU should probably have to open the provision
attribute fd if it wants its guest to be able to EINIT a provisioning
enclave.  When someone inevitably adds an EINIT LSM hook, the KVM
interface should also call it.

Second, the normal enclave interface won't allow user code to supply
an EINITTOKEN, so the KVM interface will presumably need to be
different, unless we're going to emulate EINIT by ignoring the token.
That seems like a very strange thing to do.

Powered by blists - more mailing lists