Re: [PATCH v23 12/24] x86/sgx: Linux Enclave Driver

[Stephen Smalley]

On 11/1/19 9:16 AM, Stephen Smalley wrote:
> On 10/31/19 5:17 PM, Jarkko Sakkinen wrote:
> > On Wed, Oct 30, 2019 at 09:45:05AM -0400, Stephen Smalley wrote:
> > > On 10/28/19 5:03 PM, Jarkko Sakkinen wrote:
> > > > Intel Software Guard eXtensions (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 SGX hosted software entity is disallowed to
> > > > access the memory inside the enclave enforced by the CPU. We call these
> > > > entities as enclaves.
> > > >
> > > > This commit implements a driver that provides an ioctl API to construct
> > > > and run enclaves. Enclaves are constructed from pages residing in
> > > > reserved physical memory areas. The contents of these pages can only be
> > > > accessed when they are mapped as part of an enclave, by a hardware
> > > > thread running inside the enclave.
> > > >
> > > > The starting state of an enclave consists of a fixed measured set of
> > > > pages that are copied to the EPC during the construction process by
> > > > using ENCLS leaf functions and Software Enclave Control Structure 
> > > > (SECS)
> > > > that defines the enclave properties.
> > > >
> > > > Enclave are constructed by using ENCLS leaf functions ECREATE, EADD and
> > > > EINIT. ECREATE initializes SECS, EADD copies pages from system 
> > > > memory to
> > > > the EPC and EINIT check a given signed measurement and moves the 
> > > > enclave
> > > > into a state ready for execution.
> > > >
> > > > An initialized enclave can only be accessed through special Thread 
> > > > Control
> > > > Structure (TCS) pages by using ENCLU (ring-3 only) leaf EENTER.  
> > > > This leaf
> > > > function converts a thread into enclave mode and continues the 
> > > > execution in
> > > > the offset defined by the TCS provided to EENTER. An enclave is exited
> > > > through syscall, exception, interrupts or by explicitly calling another
> > > > ENCLU leaf EEXIT.
> > > >
> > > > The permissions, which enclave page is added will set the limit for 
> > > > maximum
> > > > permissions that can be set for mmap() and mprotect(). This will
> > > > effectively allow to build different security schemes between 
> > > > producers and
> > > > consumers of enclaves. Later on we can increase granularity with LSM 
> > > > hooks
> > > > for page addition (i.e. for producers) and mapping of the enclave 
> > > > (i.e. for
> > > > consumers)
> > >
> > > Where do things stand wrt to ensuring that SGX cannot be used to 
> > > introduce
> > > executable mappings that were never authorized by the LSM (or never 
> > > measured
> > > by IMA)?
> >
> > This was the latest discussion about that subject:
> >
> > https://lore.kernel.org/linux-sgx/CALCETrWDLX68Vi4=9Dicq9ATmJ5mv36bzrc02heNYaHaBeWumQ@xxxxxxxxxxxxxx/ 
>
> So, IIUC, that means that merging the driver will create a regression 
> with respect to LSM control over executable mappings that will only be 
> rectified at some future point in time if/when someone submits LSM hooks 
> or calls to existing hooks to restore such control. That doesn't seem 
> like a good idea. Why can't you include at least that basic level of 
> control now? It is one thing to defer finer grained control or 
> SGX-specific access controls to the future - that I can understand. But 
> introducing a regression in the existing controls is not really ok.

Unless you are arguing that the existing checks on mmap/mprotect of 
/dev/sgx/enclave are a coarse-grained approximation (effectively 
requiring WX to the file or execmem for any user of SGX).