From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753691AbdCHWTt (ORCPT ); Wed, 8 Mar 2017 17:19:49 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:18074 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751209AbdCHWTq (ORCPT ); Wed, 8 Mar 2017 17:19:46 -0500 Date: Wed, 8 Mar 2017 23:18:59 +0100 From: Willy Tarreau To: Andy Lutomirski Cc: intel-sgx-kernel-dev@ml01.01.org, Jethro Beekman , Josh Triplett , "linux-kernel@vger.kernel.org" , X86 ML , Borislav Petkov , Jarkko Sakkinen Subject: Re: SGX notes from KS/LPC Message-ID: <20170308221859.GB30296@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 08, 2017 at 12:19:22PM -0800, Andy Lutomirski wrote: > On Wed, Mar 8, 2017 at 10:48 AM, Andy Lutomirski 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