On Fri, Feb 28, 2020 at 5:04 PM Dr. Greg <greg@xxxxxxxxxxxx> wrote: > > On Mon, Feb 24, 2020 at 01:13:17PM -0800, Sean Christopherson wrote: > > Hi, I hope the week is ending well for everyone. > > > On Mon, Feb 24, 2020 at 04:09:32AM -0600, Dr. Greg wrote: > > > On Sun, Feb 23, 2020 at 07:25:37PM +0200, Jarkko Sakkinen wrote: > > > > > > Good morning, I hope the week is starting 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. > > > > > > Do we misinterpret or is the driver not capable of being built in > > > modular form? > > > Correct. > > That is what we had concluded, thanks for the verification. > > > > If not, it would appear that this functionality has been lost since > > > version 19 of the driver, admittedly some time ago. > > > It was removed in v20[*]. > > We didn't see documentation of this in any of the v20 release bullet > points, hence the question. > > > > > * Allow the driver to be compiled as a module now that it no code is using > > > > its routines and it only uses exported symbols. Now the driver is > > > > essentially just a thin ioctl layer. > > > > Not having the driver available in modular form obviously makes > > > work on the driver a bit more cumbersome. > > > Heh, depends on your development environment, e.g. I do 99% of my > > testing in a VM with a very minimal kernel that even an anemic > > system can incrementally build in a handful of seconds. > > Lacking a collection of big beefy development machines with 256+ > gigabytes of RAM isn't the challenge, rebooting to test functionality > on the physical hardware is what is a bit of a nuisance. > > > > I'm assuming that the lack of module support is secondary to some > > > innate architectural issues with the driver? > > > As of today, the only part of the driver that can be extracted into > > a module is effectively the ioctl() handlers, i.e. a module would > > just be an ioctl() wrapper around a bunch of in-kernel > > functionality. At that point, building the "driver" as a module > > doesn't provide any novel benefit, e.g. very little memory > > footprint savings, reloading the module wouldn't "fix" any bugs with > > EPC management, SGX can still be forcefully disabled via kernel > > parameter, etc... And on the flip side, allowing it to be a module > > would require exporting a non-trivial number of APIs that really > > shouldn't be exposed outside of the SGX subsystem. > > > > As for why things are baked into the kernel: > > > > - EPC management: support for future enhancements (KVM and EPC cgroup). > > > > - Reclaim: don't add a unnecessary infrastructure, i.e. avoid a callback > > mechanism for which there is a single implementation. > > > > - Tracking of LEPUBKEYHASH MSRs: KVM support. > > I don't doubt the justifications, just a bit unusual for a driver, but > this driver is obviously a bit unusual. > > It will be interesting to see if the distros compile it in. We (Fedora) plan to as soon as it is merged. I even plan to ask for a backport. > Thank you for the clarifications, have a good weekend. > > Dr. Greg > > As always, > Dr. Greg Wettstein, Ph.D Worker / Principal Engineer > IDfusion, LLC > 4206 19th Ave N. Specialists in SGX secured infrastructure. > Fargo, ND 58102 > PH: 701-281-1686 CELL: 701-361-2319 > EMAIL: gw@xxxxxxxxxxxx > ------------------------------------------------------------------------------ > "We are confronted with insurmountable opportunities." > -- Walt Kelly >
