linux-kernel - Re: SGX notes from KS/LPC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170308221859.GB30296@1wt.eu>
Date:   Wed, 8 Mar 2017 23:18:59 +0100
From:   Willy Tarreau <w@....eu>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     intel-sgx-kernel-dev@...1.01.org,
        Jethro Beekman <jethro@...tanix.com>,
        Josh Triplett <josh@...htriplett.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        X86 ML <x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Subject: Re: SGX notes from KS/LPC

On Wed, Mar 08, 2017 at 12:19:22PM -0800, Andy Lutomirski wrote:
> On Wed, Mar 8, 2017 at 10:48 AM, Andy Lutomirski <luto@...nel.org> 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.

Thank you very much for the detailed explanation Andy, that was very
clear and informative!

Cheers,
Willy