Re: SGX notes from KS/LPC

[Andy Lutomirski]

On Wed, Mar 8, 2017 at 10:48 AM, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
> Hi-
>
> Here are my notes on SGX issues from KS/LPC.  It seems that I never
> emailed it out to a public list -- oops.  It may contain any number of
> typos or outright errors.

Willy Tarreau points out that I didn't define SGX at all.  For those
who haven't buried their heads in the SDM or Intel's whitepapers, SGX
is "Software Guard eXtensions".  It's an instruction set extension
that allows you to execute a special kind of user code (packaged up
into an "enclave") on supported CPUs that is protected (to a certain
extent) from software attack from other user code, the kernel, a
hypervisor, and firmware (ME, SMM, etc) and from certain classes of
hardware attacks.  SGX is available on Skylake CPUs.  Imagine
something like Apple's "secure element" except that it runs
unprivileged on the host CPU.

Alas, it has a "feature" called Launch Control that has the effect
that (a) only code that is approved by Intel can use SGX and (b) as
implemented on Windows, user packages need to not only ship their SGX
code but also the Intel-signed blob that approves their code.  In
order to get Intel's approval, you need to go through a process, and
to learn what the process is, you need to sign an NDA (as far as I
know).  I haven't signed that NDA, so I don't know what the process
is.  I don't think I'm willing to sign the NDA, either.

I've heard various people say that Launch Control functions as a root
of trust.  This is simply incorrect -- it's just licensing.  The trust
model would be fully functional without any Launch Control at all.  It
may or may not be useful to reduce the risk that malware uses SGX.

The upstream kernel has a policy that DRM kernel code can't ship
unless open source userspace for it exists.  Since open source
userspace *can't* exist for SGX as it currently stands, I think the
upstream kernel should not support it.  There's a change coming to SGX
in future CPUs called "Flexible Launch Control" (marketing speak) and
IA32_PUBKEYHASH (in the SDM) that should make it workable for upstream
Linux under certain circumstances.  The email I'm replying to here
describes how that might be done.

The technical details are described (somewhat arcanely as usual) in
the Intel SDM volume 3.  Also as usual, there is no description at all
of when IA32_PUBKEYHASH will show up.

--Andy