On Thu, Jun 13, 2019 at 04:03:24PM -0700, Xing, Cedric wrote: > > From: Stephen Smalley [mailto:sds@xxxxxxxxxxxxx] > > Sent: Thursday, June 13, 2019 10:02 AM > > > > > My RFC series[1] implements #1. My understanding is that Andy > > > (Lutomirski) prefers #2. Cedric's RFC series implements #3. > > > > > > Perhaps the easiest way to make forward progress is to rule out the > > > options we absolutely *don't* want by focusing on the potentially > > > blocking issue with each option: > > > > > > #1 - SGX UAPI funkiness > > > > > > #2 - Auditing complexity, potential enclave lock contention > > > > > > #3 - Pushing SGX details into LSMs and complexity of kernel > > > implementation > > > > > > > > > [1] > > > https://lkml.kernel.org/r/20190606021145.12604-1-sean.j.christopherson > > > @intel.com > > > > Given the complexity tradeoff, what is the clear motivating example for > > why #1 isn't the obvious choice? That the enclave loader has no way of > > knowing a priori whether the enclave will require W->X or WX? But > > aren't we better off requiring enclaves to be explicitly marked as > > needing such so that we can make a more informed decision about whether > > to load them in the first place? > > Are you asking this question at a) page granularity, b) file granularity or > c) enclave (potentially comprised of multiple executable files) granularity? > > #b is what we have on regular executable files and shared objects (i.e. > FILE__EXECMOD). We all know how to do that. > > #c is kind of new but could be done via some proxy file (e.g. sigstruct file) > hence reduced to #b. > > #a is problematic. It'd require compilers/linkers to generate such > information, and proper executable image file format to carry that > information, to be eventually picked up the loader. SELinux doesn't have > PAGE__EXECMOD I guess is because it is generally considered impractical. > > Option #1 however requires #a because the driver doesn't track which page was > loaded from which file, otherwise it can no longer be qualified "simple". Or > we could just implement #c, which will make all options simpler. But I guess > #b is still preferred, to be aligned with what SELinux is enforcing today on > regular memory pages.o Option #1 doesn't require (a). The checks will happen for every page, but in the RFCs I sent, the policies are still attached to files and processes, i.e. (b).