On Wed, May 15, 2019 at 11:27:04AM -0700, Andy Lutomirski wrote: > 2) Just like any other DSO, there are potential issues with how > enclaves deal with writable vs executable memory. This takes two > forms. First, a task should probably require EXECMEM, EXECMOD, or > similar permission to run an enclave that can modify its own text. > Second, it would be nice if a task that did *not* have EXECMEM, > EXECMOD, or similar could still run the enclave if it had EXECUTE > permission on the file containing the enclave. > > Currently, this all works because DSOs are run by mmapping the file to > create multiple VMAs, some of which are executable, non-writable, and > non-CoWed, and some of which are writable but not executable. With > SGX, there's only really one inode per enclave (the anon_inode that > comes form /dev/sgx/enclave), and it can only be sensibly mapped > MAP_SHARED. I was wrong when I said /dev/sgx/enclave creates and returns an anon inode. I was thinking of the KVM model for creating VMs. SGX creates an enclave when /dev/sgx/enclave is opened and associates the enclave with the newly opened /dev/sgx/enclave fd. Regardless, the fundamental problem remains, mmap() of EPC works on a single inode.
