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.