On Fri, May 24, 2019 at 10:54:34AM -0700, Andy Lutomirski wrote: > > > On May 24, 2019, at 10:42 AM, Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > > > Hmm, I've been thinking more about pulling permissions from the source > > page. Conceptually I'm not sure we need to meet the same requirements as > > non-enclave DSOs while the enclave is being built, i.e. do we really need > > to force userspace to fully map the enclave in normal memory? > > > > Consider the Graphene scenario where it's building an enclave on the fly. > > Pulling permissions from the source VMAs means Graphene has to map the > > code pages of the enclave with X. This means Graphene will need EXEDMOD > > (or EXECMEM if Graphene isn't careful). In a non-SGX scenario this makes > > perfect sense since there is no way to verify the end result of RW->RX. > > > > But for SGX, assuming enclaves are whitelisted by their sigstruct (checked > > at EINIT) and because page permissions affect sigstruct.MRENCLAVE, it *is* > > possible to verify the resulting RX contents. E.g. for the purposes of > > LSMs, can't we use the .sigstruct file as a proxy for the enclave and > > require FILE__EXECUTE on the .sigstruct inode to map/run the enclave? > > I think it’s sound for some but not all use cases. I would imagine that a lot > of users won’t restrict sigstruct at all — the “use this as a sigstruct” > permission will be granted to everything and maybe even to memfd. But even > users like that might want to force their enclaves to be hardened such that > writable pages are never executable, in which case Graphene may need an > exception to run. Heh, I belatedly had the same thought. See my follow-up about EXECMEM. > But maybe I’m nuts.
