Good morning, I hope the week has started well for everyone. We had raised this issue a couple of week ago, when Jarkko commented that he would be disinclined to change the signature of ioctl's once they are in place. There was no reply to that mail so we will raise the issue again, this time with a patch. As a preface, it is important to note that the only consumers of this driver are the userspace SGX runtimes. There may be some incidental interest in individuals who dabble in SGX programming but a full runtime is a substantive body of work and there will be a limited body of such software. The driver thus, primarily, needs to service the needs of these runtimes. In addition, since the proposed driver is built statically into the kernel, there is no straight forward way of providing an alternative implementation with modules. So the driver needs to support all of the runtime functionality needs. Currently Intel has the reference implementation. GOOGLE and Microsoft are using that implementation or a modified version of it. It is unclear what IBM/RH is using with their Enarx project, their web-site was indicating that as of 1/1/2020, the codebase was not yet functional, but that may have since changed. We have a second implementation that is compatible with the Intel implementation that is focused on a minimal footprint implementation. There may be a few others banging around as well. In order to deliver security solutions consistent with its design, SGX needs to have the ability to implement cryptograhic initialization policy. There have been comments that cryptographic policies would be considered after the driver is in the kernel. Unfortunately, if we follow this strategy, there will inevitably be issues surrounding the driver ABI, and based on Jarkko's comments, the ioctl signatures. So we need to resolve the issue before the driver goes in. It seems unlikely that this will delay the driver much more then it already has been delayed. We developed a patch on top of the current driver that implements a framework for such policies. This mail will be followed up with a copy of the patch, if it gets mangled we have the patch available at the following URL: ftp://ftp.enjellic.com/pub/sgx/kernel/SFLC-current.patch As the diffstat on the patch demonstrates, this infrastructure can be implemented with virtually no impact on the driver writ large. The infrastructure also results in no change to the default initialization behavior of the driver and only implements cryptographically enforced policy at the discretion of the owner/administrator of the system. We believe this demonstrates there is no technical reason for not having such support in the driver. Runtimes are free to completely ignore the functionality as are the distributions. We've scoped this to only the SGX list at this time before litigating the issue on its technical merits on LKML. Have a good day. 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 ------------------------------------------------------------------------------ "I had three strikes against me; I had a radical idea, it worked, and I was an outsider." -- Craig Venter
