Intel® Software Guard Extensions (Intel® SGX)
Discussion board focused on hardware-based isolation and memory encryption to provide extended code protection in solutions.
1453 Discussions

Intel(r) Software Guard Extensions SDK for Linux OS* now available

Dan_Zimmerman
Employee
753 Views

The Intel(r) SGX SDK for Linux* OS Open Source project is now live and can be found here:  https://01.org/intel-software-guard-extensions/

The code is hosted here:  https://github.com/01org/linux-sgx (link is external) and https://github.com/01org/linux-sgx-driver (link is external)

- Dan

0 Kudos
1 Reply
steve_t_4
Beginner
753 Views

I've been trying off-and-on to post this question over at the Intel Open Source site (01.org), but the forum there is not working. Hopefully someone here can answer this (or get the forum at 01.org working!).

It's great to see the open source release of a Linux SDK for SGX! I have a few questions regarding producing production enclaves - the information that is available is not very clear on this.

First: It appears that with the current products, any production enclave would have to have approval from Intel - Intel controls the whitelist that the launch enclave uses, so they fully control what will be allowed to run. Will they provide appropriate permissions/licenses for traditional Linux (non-commercial open source) projects? For example, I'd consider working on an enclave-protected authentication wallet/service for an ssh client, but without being able to have a deployable production enclave there's no point.

Second: I'm unclear on why production enclaves are restricted in the first place. On the Intel Developer Zone, there's a document about "Intel SGX Product Licensing" in which they say "Since the ability to launch an enclave puts developers in a position of trust on a given platform, Intel assesses the ability of applicants for production licenses to meet critical security requirements underpinning the use of Intel® SGX." Maybe I'm missing something in the security model here, but that makes no sense to me. From the developer documentation, enclaves must run in ring 3, so have no more access to sensitive system resources than any other unprivileged user-level application. As far as I can tell, no "trust" is needed in the enclave production at all. Is there some attack model or scenario in which allowing a system owner to install arbitrary enclaves would introduce some risk?

Third: Both of those questions become irrelevant if the full technology as described in the documentation is available (with BIOS support). Here's what I mean by this: In IA32_FEATURE_CONTROL, bit 17 is the "SGX Launch Control Enable" bit - according to the documentation, this would allow the platform owner (actually, any system software, but that's another issue) to load their own public key hashes that would be trusted to authenticate a launch enclave. This would have to be set through a BIOS setting (before IA32_FEATURE_CONTROL is locked), but would allow for the platform owner to load and use whatever enclaves they want to trust. Unfortunately, while this is described in the SGX documentation, it is a separate feature that may or may not be present in processors (indicated by CPUID.(EAX=07H,ECX=0H): EBX[2] = 1), and it appears this is NOT present or possible in current hardware (at least the hardware I have access to). Will Intel be releasing hardware soon that supports this feature?

Thanks for reading, and I hope responding. This is potentially exciting technology, but the issues above are show-stoppers for me before I invest any time in developing for it (and I'm sure they're concerns of anyone interested in open source SGX development).

 

0 Kudos
Reply