Messages in this thread | | | Subject | Re: [PATCH v29 00/20] Intel SGX foundations | Date | Thu, 07 May 2020 00:02:50 -0500 | From | "Haitao Huang" <> |
| |
On Wed, 06 May 2020 17:14:22 -0500, Sean Christopherson <sean.j.christopherson@intel.com> 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@redhat.com> >> >> 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
>> 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.
-- Using Opera's mail client: http://www.opera.com/mail/
| |