Re: [PATCH v19 16/27] x86/sgx: Add the Linux SGX Enclave Driver

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

On Mon, Apr 01, 2019 at 05:25:11PM +0000, Jethro Beekman wrote:
> On 2019-04-01 03:01, Jarkko Sakkinen wrote:
> > On Fri, Mar 29, 2019 at 09:20:05AM -0700, Sean Christopherson wrote:
> > > On Thu, Mar 28, 2019 at 12:05:39PM -0700, Andy Lutomirski wrote:
> > > > On Thu, Mar 28, 2019 at 6:19 AM Jarkko Sakkinen
> > > > <jarkko.sakkinen@linux.intel.com> wrote:
> > > > > 
> > > > > On Wed, Mar 27, 2019 at 01:06:11PM -0700, Sean Christopherson wrote:
> > > > > > I agree with all of the above, but unfortunately blacklisting is really
> > > > > > the only benefit that would be realized by modularizing the driver.  The
> > > > > > "driver" at this point is just the device and its ioctls, the meat of
> > > > > > the functionality has been moved into the subsystem proper.  And the few
> > > > > > remaining tidbits of functionality, e.g. sgx_encl_page_alloc() and
> > > > > > sgx_encl_alloc(), probably should be moved out of ioctl.c as well.
> > > > > 
> > > > > That is kind of core reason of having an LKM here, to wrap the uapi. It
> > > > > is not about reducing size of the kernel. It is about ability to tailor
> > > > > the uapi on stock kernels.
> > > > > 
> > > > 
> > > > As I see it, there is really only one significant benefit of modules:
> > > > reducing the size of the kernel in the case that the module isn't
> > > > loaded.
> > > 
> > > This is a much more succinct explanation of what I was attempting to say.
> > > 
> > > >   (And organizing module parameters, I suppose, but you don't,
> > > > strictly speaking, need to be able to build as a module to do that.)
> > > > SGX can be blacklisted by booting with nosgx (or, if if can't, then
> > > > that should be added).
> > > 
> > > The split lock detection series also proposed extending clearcpuid to
> > > take flags by name, a dedicated 'nosgx' may not even be necessary in the
> > > long run.
> > > 
> > > https://lkml.kernel.org/r/1549084491-57808-6-git-send-email-fenghua.yu@intel.com
> > > https://lkml.kernel.org/r/1549084491-57808-7-git-send-email-fenghua.yu@intel.com
> > > https://lkml.kernel.org/r/1549084491-57808-8-git-send-email-fenghua.yu@intel.com
> > 
> > OK, that's great. Then I just rework the LKM out...
> 
> Wait, why? I don't agree with Andy's "only" reason for LKMs, and it sounded
> like you agree.

For me the rationale for having LKM was that you can enable/disable the
functionality. For that the kernel command line would be sufficient.

I will roll v20 w/o taking it away since this is still clearly something
not concluded (won't affect other changes).

/Jarkko