> From: linux-sgx-owner@xxxxxxxxxxxxxxx [mailto:linux-sgx- > owner@xxxxxxxxxxxxxxx] On Behalf Of Andy Lutomirski > Sent: Tuesday, June 04, 2019 1:16 PM > > 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. Disallowing mmap() is not only surprising but also unnecessary. A bit off topic here. This mmap()/mprotect() discussion reminds me a question (guess for Jarkko): Now that vma->vm_file->private_data keeps a pointer to the enclave, why do we store it again in vma->vm_private? It isn't a big deal but non-NULL vm_private does prevent mprotect() from merging adjacent VMAs.
