On Fri, Nov 01, 2019 at 09:28:17AM -0400, Stephen Smalley wrote: > On 11/1/19 9:16 AM, Stephen Smalley wrote: > >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). Yes, that's the argument as running any enclave will require RWX access to /dev/sgx/enclave. EXECMEM won't trigger for SGX users as /dev/sgx/enclave must be MAP_SHARED and it's a non-private file (not backed by anonymous inode, in case I got the file terminology wrong).
