Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 24 Feb 2020 13:13:17 -0800
From:   Sean Christopherson <sean.j.christopherson@intel.com>
To:     "Dr. Greg" <greg@enjellic.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        linux-sgx@vger.kernel.org, akpm@linux-foundation.org,
        dave.hansen@intel.com, nhorman@redhat.com, npmccallum@redhat.com,
        haitao.huang@intel.com, andriy.shevchenko@linux.intel.com,
        tglx@linutronix.de, kai.svahn@intel.com, bp@alien8.de,
        josh@joshtriplett.org, luto@kernel.org, kai.huang@intel.com,
        rientjes@google.com, cedric.xing@intel.com, puiterwijk@redhat.com
Subject: Re: [PATCH v27 00/22] Intel SGX foundations
Message-ID: <20200224211317.GJ29865@linux.intel.com>
References: <20200223172559.6912-1-jarkko.sakkinen@linux.intel.com>
 <20200224100932.GA15526@wind.enjellic.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200224100932.GA15526@wind.enjellic.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

> 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[*].

> > v19:
> >
> > ... [ deleted ] ...
> >
> > * 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.

> 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.

[*] https://lkml.kernel.org/r/20190401225717.GA13450@linux.intel.com