Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752867AbcD0OGT (ORCPT ); Wed, 27 Apr 2016 10:06:19 -0400 Received: from mail-oi0-f44.google.com ([209.85.218.44]:36326 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752693AbcD0OGP (ORCPT ); Wed, 27 Apr 2016 10:06:15 -0400 MIME-Version: 1.0 In-Reply-To: <20160427081804.GC16991@gmail.com> References: <1461605698-12385-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20160426190009.GC8162@amd> <20160426194117.GA11111@amd> <20160426201154.GC11111@amd> <20160427081804.GC16991@gmail.com> From: Andy Lutomirski Date: Wed, 27 Apr 2016 07:05:53 -0700 Message-ID: Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions To: Ingo Molnar Cc: Thomas Gleixner , "linux-doc@vger.kernel.org" , Greg KH , Mathias Krause , "open list:STAGING SUBSYSTEM" , Pavel Machek , Linus Torvalds , Boris Ostrovsky , Borislav Petkov , Jarkko Sakkinen , Wan Zongshun , Peter Zijlstra , Kristen Carlson Accardi , open list , "H. Peter Anvin" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1752 Lines: 39 On Apr 27, 2016 1:18 AM, "Ingo Molnar" wrote: > > > * Andy Lutomirski 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