On Wed, Apr 22, 2020 at 12:52:56AM +0300, Jarkko Sakkinen wrote: Good day, I hope the weekend is going well for everyone. > 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. > > ... [ elided ] .. > > The current implementation requires that the firmware sets > IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately the kernel can > decide what enclaves it wants run. The implementation does not create > any bottlenecks to support read-only MSRs later on. It seems highly unlikely that a driver implementation with any type of support for read-only launch control registers would ever get into the kernel. All one needs to do is review the conversations that Matthew Garrett's lockdown patches engender to get a sense of that, ie: https://lwn.net/Articles/818277/ As a result, the proposed SGX driver needs support for cryptographic policy management before it goes into the kernel. Either the patch that we have offered or something equivalent. Absent that, the driver won't address the full needs of the development community implementing runtimes. In addition it also poses security and privacy issues that are well documented in the literature. As an aside, for those who haven't spent the last 5+ years of their life working with this technology. SGX2 hardware platforms have the ability to allow unrestricted code execution in enclave context. No amount of LSM or IMA interventions can provide any control over that. In fact, the Confidential Computing Consortium, sponsored by none other then the Linux Foundation, has at its fundamental tenant, the notion of developing an eco-system that allows the execution of code and processing of data, over which, the owner or administrator of the platform has no visibility or control. It would seem only logical that adversarial interests would indulge themseleves in those capabilities as well. With respect to SGX and these issues, cryptographic policy management is important for the same reason that 2-factor authentication is now considered standard practice in the security industry. We appreciate, Jarkko, that you feel that such infrastructure is optional, like virtualization support, and is something that can go in after the driver is mainlined. As the diffstat for our patch points out, the proposed support has virtually no impact on the driver, the same cannot be said for virtualization capabilities. Moreover, adding support for key based policy management later would require the addition of another ioctl in order to avoid ABI compatibility issues. The current initialization ioctl is best suited, from an engineering perspective, to support this type of infrastructure. In fact, the necessary support was removed from the ioctl for political reasons rather then for any valid engineering rationale on flexible launch control platforms, particularly with our patch or an equivalent approach. For the benefit of the kernel community at large, I will follow up this e-mail with a copy of our patch for review. In case anyone misses it, or it is corrupted, the patch can be pulled from the following URL: ftp://ftp.enjellic.com/pub/sgx/kernel/SFLC-current.patch We believe the patch or an equivalent approach deserves consideration for the following reasons: 1.) It does not modify the default behavior of the driver. ie. any enclave will be initialized that is presented. 2.) It enables needed functionality only at the discretion and control of the platform owner/administrator. 3.) The impact on the architecture of the driver is negligible. In closing, it is important to note that the proposed SGX driver is not available as a module. This effectively excludes any alternative implementations of the driver without replacement of the kernel at large. It also means that any platform, with SGX hardware support, running a kernel with this driver, has the potential for the security/privacy issues noted above. If key based policy management is not allowed, then the driver needs to be re-architected to have modular support so that alternative implementations or the absence of any driver support are at least tenable. Hopefully this is a reasoned technical approach to what has been a long standing issue surrounding this technology. Best wishes for a productive week. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker SGX secured infrastructure and Enjellic Systems Development, LLC autonomously self-defensive 4206 N. 19th Ave. platforms. Fargo, ND 58102 PH: 701-281-1686 EMAIL: greg@xxxxxxxxxxxx ------------------------------------------------------------------------------ "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas Edison
