On Tue, Jun 04, 2019 at 01:16:04PM -0700, Andy Lutomirski wrote: > On Tue, Jun 4, 2019 at 4:50 AM Jarkko Sakkinen > <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > > > > On Fri, May 31, 2019 at 04:31:52PM -0700, Sean Christopherson wrote: > > > SGX enclaves have an associated Enclave Linear Range (ELRANGE) that is > > > tracked and enforced by the CPU using a base+mask approach, similar to > > > how hardware range registers such as the variable MTRRs. As a result, > > > the ELRANGE must be naturally sized and aligned. > > > > > > To reduce boilerplate code that would be needed in every userspace > > > enclave loader, the SGX driver naturally aligns the mmap() address and > > > also requires the range to be naturally sized. Unfortunately, SGX fails > > > to grant a waiver to the MAP_FIXED case, e.g. incorrectly rejects mmap() > > > if userspace is attempting to map a small slice of an existing enclave. > > > > > > Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx> > > > > Why you want to allow mmap() to be called multiple times? mmap() could > > be allowed only once with PROT_NONE and denied afterwards. Is this for > > sending fd to another process that would map already existing enclave? > > > > I don't see any checks for whether the is enclave underneath. Also, I > > think that in all cases mmap() callback should allow only PROT_NONE > > as permissions for clarity even if it could called multiple times. > > > > What's the advantage to only allowing PROT_NONE? The idea here is to > allow a PROT_NONE map followed by some replacemets that overlay it for > the individual segments. Admittedly, mprotect() can do the same > thing, but disallowing mmap() seems at least a bit surprising. I was merely wondering if it is specifically for the application where a client process would mmap(MAP_FIXED) an enclave created by a server process. /Jarkko
