On Wed, 15 May 2019 16:38:58 -0500, Sean Christopherson
<sean.j.christopherson@xxxxxxxxx> wrote:
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.
If I read code in file_map_prot_check() correctly, only when you request
W+X at the same time that EXECMEM would be required for MAP_SHARED, right?
If so, I believe SGX enclaves would never need that.
