On 2019-03-19 16:41, Sean Christopherson wrote:
On Sun, Mar 17, 2019 at 11:14:29PM +0200, Jarkko Sakkinen wrote:* 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.I'm not convinced it's worth the effort to allow the driver to be compiled as a module, especially if we drop the ACPI-based probing. Making the driver loadable means the kernel can easily end up in situations where it's tracking EPC and running its reclaimer kthread, but the driver can't be loaded and can *never* be loaded, e.g. because the platform doesn't support Launch Control.
Tracking EPC etc. is necessary for KVM anyway.
And IMO encl.{c,h} belongs in the "driver" code, but to let the driver be
loadable it got shoved into the core subsystem. All of that code is
specific to running enclaves in the host, i.e. it shouldn't exist if I
compile out the driver entirely (in a future world where I want the core
SGX subsystem for virtualization purposes).
Your argument here is "something that belongs in the driver isn't, therefore we shouldn't have a loadable driver". This seems backwards to me. Instead, we should see what interface would be needed so that this stuff *can* be in the driver.
And yes, I realize this is a full 180 from my stance a year ago :)
I don't really want to rehash this argument but I think it should be a module.
-- Jethro Beekman | Fortanix
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
