linux-kernel - Re: [PATCH 0/6] Intel Secure Guard Extensions

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: <20160509070409.GA13005@kroah.com>
Date:	Mon, 9 May 2016 09:04:09 +0200
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"Dr. Greg Wettstein" <greg@...ellic.com>,
	"Austin S. Hemmelgarn" <ahferroin7@...il.com>,
	Pavel Machek <pavel@....cz>, Andy Lutomirski <luto@...nel.org>,
	Borislav Petkov <bp@...e.de>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	"open list:STAGING SUBSYSTEM" <devel@...verdev.osuosl.org>,
	Ingo Molnar <mingo@...nel.org>,
	Kristen Carlson Accardi <kristen@...ux.intel.com>,
	"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>,
	Mathias Krause <minipli@...glemail.com>,
	Wan Zongshun <Vincent.Wan@....com>
Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions

On Mon, May 09, 2016 at 08:38:25AM +0300, Jarkko Sakkinen wrote:
> On Fri, May 06, 2016 at 01:54:14PM +0200, Thomas Gleixner wrote:
> > On Fri, 6 May 2016, Jarkko Sakkinen wrote:
> > 
> > > On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> > > > It would be helpful and instructive for anyone involved in this debate
> > > > to review the following URL which details Intel's SGX licening
> > > > program:
> > > > 
> > > > https://software.intel.com/en-us/articles/intel-sgx-product-licensing
> > > 
> > > I think it would be good  to note that the licensing process is available
> > > only for Windows. For Linux you can only use debug enclaves at the
> > > moment. The default LE has "allow-all" policy for debug enclaves.
> > 
> > Which makes the feature pretty useless.
> >  
> > > > I think the only way forward to make all of this palatable is to
> > > > embrace something similar to what has been done with Secure Boot.  The
> > > > Root Enclave Key will need to be something which can be reconfigured
> > > > by the Platform Owner through BIOS/EFI.  That model would take Intel
> > > > off the hook from a security perspective and establish the notion of
> > > > platform trust to be a bilateral relationship between a service
> > > > provider and client.
> > > 
> > > This concern has been raised many times now. Sadly this did not make
> > > into Skyle but in future we will have one shot MSRs (can be set only
> > > once per boot cycle) for defining your own root of trust.
> > 
> > We'll wait for that to happen.
> 
> I fully understand if you (and others) want to keep this standpoint but
> what if we could get it to staging after I've revised it with suggested
> changes and internal changes in my TODO? Then it would not pollute the
> mainline kernel but still would be easily available for experimentation.

No, staging is not a "dumping ground", it's for code that is not ready
to be merged, and has some work left to do on it and it shows forward
progress on that goal.  I don't put things in there that the maintainers
of the subsystems it affects do not want merged.  See the many previous
examples of code that has been rejected for staging as examples of this.

sorry,

greg k-h