[PATCH 0/6] Intel Secure Guard Extensions

[Andy Lutomirski]

On Apr 27, 2016 1:18 AM, "Ingo Molnar" <mingo at kernel.org> wrote:
>
>
> * Andy Lutomirski <luto at amacapital.net> wrote:
>
> > > What new syscalls would be needed for ssh to get all this support?
> >
> > This patchset or similar, plus some user code and an enclave to use.
> >
> > Sadly, on current CPUs, you also need Intel to bless the enclave.  It looks like
> > new CPUs might relax that requirement.
>
> That looks like a fundamental technical limitation in my book - to an open source
> user this is essentially a very similar capability as tboot: it only allows the
> execution of externally blessed static binary blobs...
>
> I don't think we can merge any of this upstream until it's clear that the hardware
> owner running open-source user-space can also freely define/start his own secure
> enclaves without having to sign the enclave with any external party. I.e.
> self-signed enclaves should be fundamentally supported as well.

Certainly, if this were a *graphics* driver, airlied would refuse to
merge it without open source userspace available.

We're all used to Intel sending patches that no one outside Intel can
test without because no one has the hardware.  Heck, I recently sent a
vdso patch that *I* can't test.  But in this case I have the hardware
and there is no way that I can test it, and I don't like this at all.

See my earlier comments about not allowing user code to provide
EINITTOKEN.  Implementing that would mostly solve this problem, with
the big caveat that it may be impossible to implement that suggestion
until Intel changes its stance (which is clearly in progress, given
the recent SDM updates).

This could easily end up bring a CNL-only feature in Linux.  (Or
whatever generation that change is in.)

--Andy