> On May 17, 2019, at 11:21 AM, Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > >> On Fri, May 17, 2019 at 11:04:22AM -0700, Linus Torvalds wrote: >> On Fri, May 17, 2019 at 10:55 AM Sean Christopherson >> <sean.j.christopherson@xxxxxxxxx> wrote: >>> >>> In this snippet, IS_PRIVATE() is true for anon inodes, false for >>> /dev/sgx/enclave. Because EPC memory is always shared, SELinux will never >>> check PROCESS__EXECMEM for mprotect() on/dev/sgx/enclave. >> >> Why _does_ the memory have to be shared? Shared mmap() is >> fundamentally less secure than private mmap, since by definition it >> means "oh, somebody else has access to it too and might modify it >> under us". >> >> Why does the SGX logic care about things like that? Normal executables >> are just private mappings of an underlying file, I'm not sure why the >> SGX interface has to have that shared thing, and why the interface has >> to have a device node in the first place when you have system calls >> for setup anyway. >> >> So why don't the system calls just work on perfectly normal anonymous >> mmap's? Why a device node, and why must it be shared to begin with? > > I agree that conceptually EPC is private memory, but because EPC is > managed as a separate memory pool, SGX tags it VM_PFNMAP and manually > inserts PFNs, i.e. EPC effectively it gets classified as IO memory. > > And vmf_insert_pfn_prot() doesn't like writable private IO mappings: > > BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); I don’t see how it could be anonymous even in principle. The kernel can’t *read* the memory — how could we possibly CoW it? And we can’t share an RO backing pages between two different enclaves because the CPU won’t let us — each EPC page belongs to a particular enclave. And fork()ing an enclave is right out. So I agree that MAP_ANONYMOUS would be nice conceptually, but I don’t see how it would work.
