Hi, I hope the weekend is going well for everyone. On Fri, May 06, 2016 at 02:39:44PM +0300, 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. As others have noted, unfortunately, this renders the technology largely useless on Linux, at least for anything beyond experimentation. That is somewhat strange given that one of the primary intentions of the technology is to push applications into untrusted cloud environments, particularly given the use of Linux in the 'cloud'. So I guess Azure is the only security beneficiary at this time... :-) I assume that Intel will be releasing a launch enclave with its upcoming Linux SDK? > > 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. It is encouraging to hear that Intel will be implementing one shot MSR's for the identity modulus signature. That would be consistent with what we would advocate for. This now means the security of SGX on 'unlocked' platforms, at least from a trust perspective, will be dependent on using TXT so as to provide a hardware root of trust on which to base the SGX trust model. I was out walking with Izzy our Golden Retriever last night and as I thought about the implicatioins of all this I think the solution, at least as we would implement it, will tie together rather nicely. I would assume that everyone is using signed Launch Control Policies (LCP) as we are. This means that TXT/tboot already has access to the public key which is used for the LCP data file signature. It would seem logical to have tboot compute the signature on that public key and program that signature into the module signature registers. That would tie the hardware root of trust to the SGX root of trust. If that is undesirable the other alternative would be to pass a custom LCP policy element into tboot which would define the desired SGX trust signature. It is unfortunate that SGX took the path it did on Linux. We actually have application for the technology now in our security supervisor. When you say that unlocked SGX did not make it into Skylake does this mean we need to wait for a new micro-architecture or a die shrink? Given that tick/tock is now expanding in time it would be useful to have unlocked SGX be one of the extension features of Skylake. Otherwise there is certainly no rush for the Linux driver... :-) > /Jarkko Have a good week. Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@xxxxxxxxxxxx ------------------------------------------------------------------------------ "If you get to thinkin' you're a person of some influence, try orderin' somebody else's dog around." -- Cowboy Wisdom _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
