linux-kernel - Re: [PATCH v16 18/22] platform/x86: Intel SGX 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: <a4895bc5-3234-8555-2709-1407dd1bf8e7@intel.com>
Date:   Tue, 6 Nov 2018 08:57:39 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        x86@...nel.org, platform-driver-x86@...r.kernel.org,
        linux-sgx@...r.kernel.org
Cc:     nhorman@...hat.com, npmccallum@...hat.com, serge.ayoun@...el.com,
        shay.katz-zamir@...el.com, haitao.huang@...el.com,
        andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
        kai.svahn@...el.com, Suresh Siddha <suresh.b.siddha@...el.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v16 18/22] platform/x86: Intel SGX driver

On 11/6/18 8:40 AM, Sean Christopherson wrote:
>> +struct sgx_encl {
>> +	unsigned int flags;
>> +	uint64_t attributes;
>> +	uint64_t xfrm;
>> +	unsigned int page_cnt;
>> +	unsigned int secs_child_cnt;
>> +	struct mutex lock;
>> +	struct mm_struct *mm;
>> +	struct file *backing;
> Is there any particular reason why the kernel manages the backing for
> the enclave and the PCMDs?  Could we have userspace provide the backing
> either through the ECREATE ioctl() or maybe a completely new ioctl(),
> e.g. to give userspace the option to back the enclave with a NVDIMM
> instead of RAM?  A separate ioctl() with control flags might give us
> some flexibility in the future, e.g. maybe there are use cases where
> userspace would prefer to kill enclaves rather than swap EPC.

I'll take the blame for this little nugget.  I think it was my idea.  We
have a few of these kernel-internal shmfs files.  But, as you note, it
would be really nice if they were subject to the normal memory APIs and
we could set NUMA policies on them and so forth.

We could just wire the NUMA (and other) APIs up to the SGX VMA.