On Thu, May 7, 2020 at 1:03 AM Haitao Huang <haitao.huang@xxxxxxxxxxxxxxx> wrote: > > On Wed, 06 May 2020 17:14:22 -0500, Sean Christopherson > <sean.j.christopherson@xxxxxxxxx> wrote: > > > 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. > > > > For larger size mmap, I think it requires enabling vm overcommit mode 1: > echo 1 | sudo tee /proc/sys/vm/overcommit_memory Which means the default experience isn't good.
