On Mon, Jul 01, 2019 at 01:03:51PM -0700, Xing, Cedric wrote: > > From: Andy Lutomirski [mailto:luto@xxxxxxxxxx] > > Sent: Monday, July 01, 2019 12:33 PM > > > > It does make sense, but I'm not sure it's correct to assume that any LSM > > policy will always allow execution on enclave source pages if it would > > allow execution inside the enclave. As an example, here is a policy > > that seems reasonable: > > > > Task A cannot execute dynamic non-enclave code (no execmod, no execmem, > > etc -- only approved unmodified file pages can be executed). > > But task A can execute an enclave with MRENCLAVE == such-and-such, and > > that enclave may be loaded from regular anonymous memory -- the > > MRENCLAVE is considered enough verification. > > You are right. That's a reasonable policy. But I still can't see the need for > SGX_EXECUNMR, as MRENCLAVE is considered enough verification. That assumes the enclave/loader developer will never make a mistake, and that policy owners are going to do a deep dive on the EEXTEND values for an enclave (and will never make a mistake). User errors aside, EXECUNMR would also be useful in conjunction with MRSIGNER, e.g. allow all enclaves signed by X, but disallow unmeasured code.
