On Tue, Jul 09, 2019 at 07:06:34PM +0300, Jarkko Sakkinen wrote: > On Mon, Jul 08, 2019 at 09:19:32AM -0700, Sean Christopherson wrote: > > > 2. Probably some "user story" type of examples would help with the > > > discussion overall [1] i.e. how one would use this for > > > her own good. > > > > The compelling story is Andy's original concern that userspace could > > circumvent existing security policies by running code in an enclave. > > > > AIUI, closing the LSM loophole is the minimal requirement to get SGX > > upstreamed. The extensive discussion has largely been focused on > > ensuring that whatever mechanism is used to close the loophole will > > play nice with future SGX functionality and/or LSM security policies. > > OK, might be getting here where I fall out of the wagon so: > > Doesn't Andy's example anyway require a process that has privileges to > make pages executable i.e. it could run arbitrary code even without an > enclave? Ah, no. He did raise that concern, but it'd only be an issue if the enclave fd were backed by an anon inode, in which case all enclaves would need EXECMEM in order to gain PROT_EXEC on EPC. Because the fd is backed /dev/sgx/enclave, userspace just needs FILE__EXECUTE on /dev/sgx/enclave.
