From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754349AbdCHU5y (ORCPT ); Wed, 8 Mar 2017 15:57:54 -0500 Received: from mail.kernel.org ([198.145.29.136]:36988 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753818AbdCHU5v (ORCPT ); Wed, 8 Mar 2017 15:57:51 -0500 MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Wed, 8 Mar 2017 12:19:22 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: SGX notes from KS/LPC 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. --Andy