On Fri, May 24, 2019 at 10:54:34AM -0700, Andy Lutomirski wrote:

quoted

On May 24, 2019, at 10:42 AM, Sean Christopherson [off-list ref] 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.