linux-kernel - Re: [PATCH v38 10/24] mm: Add vm

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: <e4bcb25f-581a-da93-502b-b8f73e28286a@intel.com>
Date:   Thu, 24 Sep 2020 13:10:31 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Haitao Huang <haitao.huang@...ux.intel.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        linux-sgx@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>,
        Jethro Beekman <jethro@...tanix.com>,
        Darren Kenny <darren.kenny@...cle.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        asapek@...gle.com, Borislav Petkov <bp@...en8.de>,
        "Xing, Cedric" <cedric.xing@...el.com>, chenalexchen@...gle.com,
        Conrad Parker <conradparker@...gle.com>, cyhanish@...gle.com,
        "Huang, Haitao" <haitao.huang@...el.com>,
        Josh Triplett <josh@...htriplett.org>,
        "Huang, Kai" <kai.huang@...el.com>,
        "Svahn, Kai" <kai.svahn@...el.com>, Keith Moyer <kmoy@...gle.com>,
        Christian Ludloff <ludloff@...gle.com>,
        Neil Horman <nhorman@...hat.com>,
        Nathaniel McCallum <npmccallum@...hat.com>,
        Patrick Uiterwijk <puiterwijk@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>, yaozhangx@...gle.com
Subject: Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()

On 9/24/20 1:01 PM, Sean Christopherson wrote:
>> In pseudo-C, it's something logically like this for the "nice" case:
>>
>> 	ptr = mmap("/some/executable", PROT_EXEC);
>> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
>> 	mmap(sgx_fd);
>> 	EENTER;
>>
>> And we're trying to thwart:
>>
>> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
>> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
>> 	mmap(sgx_fd);
>> 	EENTER;
>>
>> because that loads data into the enclave which is executable but which
>> was not executable normally.  But, we're allowing this from anonymous
>> memory, so this would seem to work:
>>
>> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
>> 	buffer = malloc(PAGE_SIZE);
>> 	memcpy(buffer, ptr, PAGE_SIZE);
>> 	// need mprotect(buf, PROT_EXEC)???
>> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
>> 	mmap(sgx_fd);
>> 	EENTER;
>>
>> and give the same result.  What am I missing?
> The last example, where the enclave is copied to a buffer, is out of scope
> for noexec.  But, it is in scope for LSMs, e.g. for this last example, we
> could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an
> SGX specific equivalent).

Why don't we just declare enclave memory as "out of scope for noexec" in
the same way that anonymous memory is, and just discard this patch?
That doesn't seem too much of a stretch.