On Wed, Apr 17, 2019 at 01:39:10PM +0300, Jarkko Sakkinen wrote: Good morning, I hope this note finds the impending end of the work week going well for everyone. First of all, a thank you to Jarkko for his efforts in advancing this driver, a process that can be decidedly thankless. Our apologies in advance for contributing to this phenomenon. > Intel(R) SGX is a set of CPU instructions that can be used by > applications to set aside private regions of code and data. The code > outside the enclave is disallowed to access the memory inside the > enclave by the CPU access control. In a way you can think that SGX > provides inverted sandbox. It protects the application from a > malicious host. Unfortunately, in its current implementation, the driver will not protect a host from malicious enclaves. If it advances in its current form, the mainline Linux kernel will be implementing a driver with known and documented security issues. In addition, the driver breaks all existing SGX software by breaking compatibility with what is a 3+ year ABI provided by the existing driver. This seems to contravene the well understood philosophy that Linux doesn't, if at all possible, break existing applications, something that we believe can be easily prevented if those interested in these issues choose to read on. The following reflections and code come from a team that has been active in SGX development, since before hardware was even publically available. A team that has authored a complete re-implementation of all of the SGX runtime infrastructure, which is the only consumer of the services provided by an SGX driver. A team that has also authored and maintains a significant cohort of SGX based applications. So I believe we speak from a vantage point of experience with respect to these issues and not from a 'bike-shedding' or political perspective. The fundamental problem is that the proposed driver lacks an enclave initialization policy mechanism consistent with the security guarantees that SGX hardware is designed to deliver. SGX is designed to provide system architects a framework for building IAGO resistent security architectures through the use of cryptographically defined identities. Other then an attempt to limit acccess to the PROVISION attribute, the driver makes no attempt to regulate, in a cryptographically secure fashion, what enclaves can be initialized, who can initialize them or what characteristics they can be initialized with. The security implications of this were recently documented in a paper by researchers at Graz, here is the link for those interested: https://arxiv.org/pdf/1702.08719.pdf Both the current controls for enclave access to the PROVISION attribute and the security controls that are being proposed to emerge for the driver, sometime in the future, suffer from being dependent on discretionary access controls, ie. file privileges, that can be defeated by a privilege escalation attack. Those of us building architectures on top of this technology have a need to certify that an application will provide security contracts robust in the face of a privilege escalation event or platform compromise. To be very blunt, and my apologies for doing so, the design for this driver has been driven by idealogy rather then by technology. Our focus with this e-mail and proposed driver modification is an attempt to satisfy both technical requirements and political idealogy, if that is even possible. When we raised these issues six months ago, we were told that we were handwaving bloat into the kernel. We take a criticism like that very seriously so we are returning with code, in what we believe is 'bloat-free' form. The attached patch, against the jarkko-sgx/master branch of Jarkko's driver repository, provides a framework that implements cryptographically secure enclave initialization policies. The patch and it's signature are also available from the following URL's: ftp://ftp.idfusion.net/pub/idfusion/jarkko-master-SFLC.patch ftp://ftp.idfusion.net/pub/idfusion/jarkko-master-SFLC.patch.asc The modification, in series form, is also available in the following GIT repository: git://git.idfusion.net/src/linux-sgx/in-tree jarkko-master-SFLC The driver modification implements cryptographically secure enclave initialization only if the platform owner chooses to do so and does not limit the development of alternative strategies in the future. It also allows the platform owner to choose the ability to remain compatible with existing runtimes and applications. The policy architecture allows just about any conceivable initialization policy to be implemented and in any combination. It supports both a plurality of launch enclaves as well as support for multiple signing keys if a token-less approach is desired. It also provides cryptographically secure control of access to the PROVISION attribute and the ability to completely block access to the attribute if that is desired. The driver modification has been extensively tested in all of these scenarios, including combinations thereof. We just completed a major round of development that was based on Flexible Launch Control platforms and deployed onto fixed launch control platforms using the out-of-tree driver, without a need to maintain disparate runtimes. On that note, given that the new driver API is completely incompatible with all of the existing runtime software in the field, we believe the issue of proper testing of this driver is an open problem. I'm assuming that Intel has a yet to be released PSW/SDK that supports the driver, otherwise our enhancements to the driver is the only way that it can experience legitimate field testing. The interface for using the policy management framework is straight forward. The following three pseudo-files are available: /sys/kernel/security/sgx/launch_keys /sys/kernel/security/sgx/provisioning_keys /sys/kernel/security/sgx/signing_keys The SHA256 hashes of the cryptographic keys used to sign enclaves (MRSIGNER values) are written into these files, ie, the following command: echo "SHA256_HASH" >| /sys/kernel/security/sgx/signing_keys Would only allow enclaves to be initialized whose MRSIGNER value matches the SHA256_HASH value. The 'launch_keys' file maintains a list of signer signatures that are allowed to initialize enclaves with the EINITTOKEN attribute set. The 'provisioning_keys' file maintains a list of signer signatures that are allowed to initialize enclaves with the PROVISION attribute set. Writing the 'lock' keyword to a file permanently blocks any further directives from being recognized. At that point, a very targeted ring-0 attack would need to be conducted to circumvent the enclave initialization policies. This provides a framework that allows a flexible launch control platform to attain the approximate security guarantees offered by a fixed launch control platform. If the platform owner chooses to do nothing, the driver will initialize any enclave that is presented to it. FWIW, we have close to a century of enterprise system's administration experience on our team and we could not envision any competent system's administrator, concerned about security, who would allow such a configuration. So that is how it all works, the changelogs in the GIT repository have much more extensive documentation. We fit the entire architecture into approximately one page of memory, which seems to be a minor amount of bloat for everyone getting to do whatever they want to do, including leaving Linux mainline with a secure driver implementation. Here is the diffstat: --------------------------------------------------------------------------- arch/x86/include/uapi/asm/sgx.h | 2 + arch/x86/kernel/cpu/sgx/driver/Makefile | 1 + arch/x86/kernel/cpu/sgx/driver/driver.h | 7 + arch/x86/kernel/cpu/sgx/driver/ioctl.c | 88 ++++- arch/x86/kernel/cpu/sgx/driver/main.c | 5 + arch/x86/kernel/cpu/sgx/driver/policy.c | 584 ++++++++++++++++++++++++++++++++ arch/x86/kernel/cpu/sgx/main.c | 27 +- arch/x86/kernel/cpu/sgx/sgx.h | 3 +- 8 files changed, 704 insertions(+), 13 deletions(-) --------------------------------------------------------------------------- With respect to a mainline Linux driver at large, an issue that we believe needs clarification is whether or not a mandate will be issued by Intel to OEM's that Flexible Launch Control is mandatory on all platforms that are henceforth shipped. Otherwise the mainline Linux driver will be in the unenviable position of only working sporadically and will not be a universal solution for all hardware. We have a solution for that as well, but the above is probably enough cannon fodder for debate so we will leave that sleeping dog lie for the time being. Hopefully all of the above is helpful for enhancing the quality of the Linux SGX eco-system. Best wishes for a productive weekend. Dr. 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@enjellic.com ------------------------------------------------------------------------------ "I can only provide the information, I can't make you hear it." -- Shelley Bainter