Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <7706b2aa71312e1f0009958bcab24e1e9d8d1237.camel@linux.intel.com>
 <598cd050-f0b5-d18c-96a0-915f02525e3e@fortanix.com> <20181219091148.GA5121@linux.intel.com>
 <613c6814-4e71-38e5-444a-545f0e286df8@fortanix.com> <20181219144515.GA30909@linux.intel.com>
 <CALCETrW_8LnitFamYUU7POHFOJFxLO7ESFUdS=aeG_SOvHVPkw@mail.gmail.com>
 <20181221162825.GB26865@linux.intel.com> <105F7BF4D0229846AF094488D65A0989355A45B6@PGSMSX112.gar.corp.intel.com>
 <20190108220946.GA30462@linux.intel.com> <CALCETrU7Zb8L8eTYZg3bAB1Gfw1orUfeQmXjVy1_R-kfBeweVA@mail.gmail.com>
 <20190110174550.GJ6589@linux.intel.com>
In-Reply-To: <20190110174550.GJ6589@linux.intel.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Thu, 10 Jan 2019 13:36:15 -0800
Message-ID: <CALCETrXMW+tUyTaMmmdhGciqbktiqH6NCuLZbBqfhcnzCgMbnA@mail.gmail.com>
Subject: Re: x86/sgx: uapi change proposal
To:     Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc:     Andy Lutomirski <luto@kernel.org>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        "Huang, Kai" <kai.huang@intel.com>,
        Jethro Beekman <jethro@fortanix.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "x86@kernel.org" <x86@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
        Josh Triplett <josh@joshtriplett.org>,
        Haitao Huang <haitao.huang@linux.intel.com>,
        "Dr . Greg Wettstein" <greg@enjellic.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jan 10, 2019 at 9:46 AM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > 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.  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.
> > 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.
>
> Does it even matter if just leave EINITTOKENKEY attribute unprivileged
> given that Linux requires that MSRs are writable? Maybe I'll just
> whitelist that attribute to any enclave?
>

I would at least make it work like the PROVISIONKEY bit (or whatever
it's called).  Or just deny it at first.  It's easy to start allowing
it if we need to down the road, but it's harder to start denying it.

Also, I don't really want to see some SDK invoke a launch enclave
because that's how it works on Windows and then do nothing with the
resulting EINITOKEN.  If we don't allow it, then the SDKs will be
forced to do a better job, which is probably a good thing.