lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 07 May 2020 17:31:39 -0500
From:   "Haitao Huang" <haitao.huang@...ux.intel.com>
To:     "Nathaniel McCallum" <npmccallum@...hat.com>
Cc:     "Sean Christopherson" <sean.j.christopherson@...el.com>,
        "Jarkko Sakkinen" <jarkko.sakkinen@...ux.intel.com>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-sgx@...r.kernel.org, akpm@...ux-foundation.org,
        dave.hansen@...el.com, "Neil Horman" <nhorman@...hat.com>,
        "Huang, Haitao" <haitao.huang@...el.com>,
        andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
        "Svahn, Kai" <kai.svahn@...el.com>, bp@...en8.de,
        "Josh Triplett" <josh@...htriplett.org>, luto@...nel.org,
        kai.huang@...el.com, "David Rientjes" <rientjes@...gle.com>,
        "Xing, Cedric" <cedric.xing@...el.com>,
        "Patrick Uiterwijk" <puiterwijk@...hat.com>
Subject: Re: [PATCH v29 00/20] Intel SGX foundations

On Thu, 07 May 2020 11:49:15 -0500, Nathaniel McCallum  
<npmccallum@...hat.com> wrote:

> On Thu, May 7, 2020 at 1:03 AM Haitao Huang
> <haitao.huang@...ux.intel.com> wrote:
>>
>> On Wed, 06 May 2020 17:14:22 -0500, Sean Christopherson
>> <sean.j.christopherson@...el.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@...hat.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
>
> Which means the default experience isn't good.
>


Yes, it is not good default. But this is not sgx specific IIUC. Normal  
applications would have the same issue if they ask for large mapping than  
whatever limit kernel enforces by default.

Powered by blists - more mailing lists