From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757792AbcEFQWR (ORCPT ); Fri, 6 May 2016 12:22:17 -0400 Received: from mail-oi0-f48.google.com ([209.85.218.48]:35962 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755704AbcEFQWQ (ORCPT ); Fri, 6 May 2016 12:22:16 -0400 MIME-Version: 1.0 In-Reply-To: <20160506112334.GB24074@intel.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> <20160506112334.GB24074@intel.com> From: Andy Lutomirski Date: Fri, 6 May 2016 09:21:55 -0700 Message-ID: Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions To: Jarkko Sakkinen Cc: Ingo Molnar , Pavel Machek , "linux-doc@vger.kernel.org" , Boris Ostrovsky , Thomas Gleixner , Greg KH , Mathias Krause , Borislav Petkov , "open list:STAGING SUBSYSTEM" , Wan Zongshun , Kristen Carlson Accardi , open list , Linus Torvalds , "H. Peter Anvin" , Peter Zijlstra 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 Fri, May 6, 2016 at 4:23 AM, Jarkko Sakkinen wrote: > On Wed, Apr 27, 2016 at 10:18:05AM +0200, 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. > > Post Skylake we will have a set of MSRs for defining your own root of > trust: IA32_SGXLEPUBKEYHASH. > > Andy had a concern that you could set root of trust multiple times, > which could lead to potential attack scenarios. These MSRs are one-shot. > ENCLS will fail if the launch control is locked. There's no possiblity > to have a root of trust that is unlocked. If this is actually true, can you ask the architecture folks to clarify their manual. The MSR description in table 35-2 says "Write permitted if CPUID.(EAX=12H,ECX=0H): EAX[0]=1 && IA32_FEATURE_CONTROL[17] = 1 && IA32_FEATURE_CONTROL[0] = 1" 39.1.4 says "If IA32_FEATURE_CONTROL is locked with bit 17 set, IA32_SGXLEPUBKEYHASH MSRs are reconfigurable (writeable). If either IA32_FEATURE_CONTROL is not locked or bit 17 is clear, the MSRs are read only. By leaving these MSRs writable, system SW or a VMM can support a plurality of Launch Enclaves for hosting multiple execution environments." This does not sound like one-shot to me. It sounds quite clear, in fact, that it's *not* one-shot so a "plurality" of these things are supported. --Andy