On Thu, May 30, 2019 at 02:23:07PM -0700, Andy Lutomirski wrote: > On Thu, May 30, 2019 at 2:16 PM Sean Christopherson > <sean.j.christopherson@xxxxxxxxx> wrote: > > > > On Thu, May 30, 2019 at 12:20:45PM -0700, Andy Lutomirski wrote: > > > On Thu, May 30, 2019 at 11:01 AM Sean Christopherson > > > <sean.j.christopherson@xxxxxxxxx> wrote: > > > > > > > > On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote: > > > > > Enclave file -- that is, the file backing the vma from which the data is loaded. > > > > > > > > It wasn't explicitly called out in Andy's proposal(s), but the idea is > > > > that the SGX driver would effectively inherit permissions from the source > > > > VMA (EADD needs a source for the initial value of the encave page). > > > > > > I actually meant for it to *not* work like this. I don't want the > > > source VMA to have to be VM_EXEC. I think the LSM should just check > > > permissions on ->vm_file. > > > > But if ->vm_file is NULL, i.e. the enclave is not backed by a file, > > then PROCESS__EXECMEM is required (or more likely, ENCLAVE__EXECMEM). > > > > If ->vm_file is NULL, then I think some privilege is needed. I > suppose the policy could have a new lesser permission EXECUNTRUSTED > which is like EXECMOD but you can't modify it. I'm not convinced this > is particular important. Assuming MRENCLAVE generated by Graphene or any other hosting scheme are stable[1], then avoiding EXEC<whatever> means the user can effectively whitelist what enclaves are runnable by Graphene, even if the kernel doesn't implement security_enclave_create/init(). I agree that it probably isn't all that important, it's more of a "why not" argument, i.e. what is gained by not using sigstruct as a proxy? [1] What in the world is being attested if MRENCLAVE isn't stable?
