On Wed, May 06, 2020 at 05:42:42PM -0400, Nathaniel McCallum wrote: > Tested on Enarx. This requires a patch[0] for v29 support. > > Tested-by: Nathaniel McCallum <npmccallum@xxxxxxxxxx> > > However, we did uncover a small usability issue. See below. > > [0]: https://github.com/enarx/enarx/pull/507/commits/80da2352aba46aa7bc6b4d1fccf20fe1bda58662 ... > > * Disallow mmap(PROT_NONE) from /dev/sgx. Any mapping (e.g. anonymous) can > > be used to reserve the address range. Now /dev/sgx supports only opaque > > mappings to the (initialized) enclave data. > > The statement "Any mapping..." isn't actually true. > > Enarx creates a large enclave (currently 64GiB). This worked when we > created a file-backed mapping on /dev/sgx/enclave. However, switching > to an anonymous mapping fails with ENOMEM. We suspect this is because > the kernel attempts to allocate all the pages and zero them but there > is insufficient RAM available. We currently work around this by > creating a shared mapping on /dev/zero. Hmm, the kernel shouldn't actually allocate physical pages unless they're written. I'll see if I can reproduce. > If we want to keep this mmap() strategy, we probably don't want to > advise mmap(ANON) if it allocates all the memory for the enclave ahead > of time, even if it won't be used. This would be wasteful. > > OTOH, having to mmap("/dev/zero") seems a bit awkward.
