linux-kernel - Re: [PATCH v33 11/21] x86/sgx: Linux Enclave Driver

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d7bee9a1-256b-d4ea-c146-ad353a913ae0@intel.com>
Date:   Tue, 27 Oct 2020 08:20:00 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>, x86@...nel.org,
        linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Jethro Beekman <jethro@...tanix.com>,
        Haitao Huang <haitao.huang@...ux.intel.com>,
        Chunyang Hui <sanqian.hcy@...fin.com>,
        Jordan Hand <jorhand@...ux.microsoft.com>,
        Nathaniel McCallum <npmccallum@...hat.com>,
        Seth Moore <sethmo@...gle.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Suresh Siddha <suresh.b.siddha@...el.com>,
        akpm@...ux-foundation.org, andriy.shevchenko@...ux.intel.com,
        asapek@...gle.com, cedric.xing@...el.com, chenalexchen@...gle.com,
        conradparker@...gle.com, cyhanish@...gle.com,
        haitao.huang@...el.com, josh@...htriplett.org, kai.huang@...el.com,
        kai.svahn@...el.com, kmoy@...gle.com, ludloff@...gle.com,
        luto@...nel.org, nhorman@...hat.com, puiterwijk@...hat.com,
        rientjes@...gle.com, tglx@...utronix.de, yaozhangx@...gle.com
Subject: Re: [PATCH v33 11/21] x86/sgx: Linux Enclave Driver

On 10/27/20 3:05 AM, Borislav Petkov wrote:
> On Mon, Oct 26, 2020 at 02:26:13PM -0700, Dave Hansen wrote:
>> What were you concerned about here?  Was it how long the syscall could
>> take, or that one user could exhaust all the enclave memory in one call?
> More the latter. And generally, to have a sanity-check on all requests
> coming from luserspace.

I can't think of a *lot* of spots where we have sanity checks like this
for memory.  We have cgroups and the overcommit limits.  But, in
general, folks can allocate as much memory as they want until
allocations start to fail.

Should SGX be any different?

If we had a sanity check that said, "you can only allocate 1/2 of
enclave memory", wouldn't that just make somebody mad because they want
one big enclave?

Or, do you just want a sanity check to see if, up front, the user is
asking for more enclave memory than there is on the *whole* system?
That's also sane, but it doesn't take overcommit into account.  That's
why, for instance, we have vm.overcommit_ratio for normal memory.

BTW, I think we all agree that a cgroup controller for enclave memory is
going to be needed eventually.