linux-kernel - Re: [PATCH v20 00/28] Intel SGX1 support

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: <49b28ca1-6e66-87d9-2202-84c58f13fb99@fortanix.com>
Date:   Fri, 19 Apr 2019 21:19:31 +0000
From:   Jethro Beekman <jethro@...tanix.com>
To:     Andy Lutomirski <luto@...capital.net>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        "Dr. Greg" <greg@...ellic.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "npmccallum@...hat.com" <npmccallum@...hat.com>,
        "Ayoun, Serge" <serge.ayoun@...el.com>,
        "Katz-zamir, Shay" <shay.katz-zamir@...el.com>,
        "Huang, Haitao" <haitao.huang@...el.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Svahn, Kai" <kai.svahn@...el.com>, Borislav Petkov <bp@...en8.de>,
        Josh Triplett <josh@...htriplett.org>,
        "Huang, Kai" <kai.huang@...el.com>,
        David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH v20 00/28] Intel SGX1 support



Jethro Beekman | Fortanix

On 2019-04-19 14:15, Andy Lutomirski wrote:
> 
> 
> 
> 
>> On Apr 19, 2019, at 1:54 PM, Jethro Beekman <jethro@...tanix.com> wrote:
>>
>>> On 2019-04-19 13:50, Thomas Gleixner wrote:
>>>> On Fri, 19 Apr 2019, Jethro Beekman wrote:
>>>>> On 2019-04-19 13:39, Thomas Gleixner wrote:
>>>>>> On Fri, 19 Apr 2019, Jethro Beekman wrote:
>>>>>>
>>>>>>> On 2019-04-19 08:27, Andy Lutomirski wrote:
>>>>>>> There are many,
>>>>>>> many Linux systems that enforce a policy that *all* executable text
>>>>>>> needs to come from a verified source.  On these systems, you can't
>>>>>>> mmap some writable memory, write to it, and then change it to
>>>>>>> executable.
>>>>>>
>>>>>> How is this implemented on those systems? AFAIK there's no kernel config
>>>>>> option that changes the semantics of mmap as you describe.
>>>>>
>>>>> That has nothing to do with mmap() semantics. You mmap() writeable memory
>>>>> and then you change the permissions via mprotect(). mprotect() calls into
>>>>> LSM and depending on policy and security model this will reject the
>>>>> request.
>>>>>
>>>>> Andy was pointing out that the SGX ioctl bypasses the LSM mechanics which
>>>>> is obviously a bad thing.
>>>>
>>>> We could modify the driver such that when you call ioctl EADD, the page
>>>> table permissions need to be the PAGEINFO.SECINFO.FLAGS | PROT_WRITE,
>>>> otherwise you get EPERM or so. After EADD, if you want, you can restrict
>>>> the page table permissions again using mprotect but the page table
>>>> permissions don't really matter for SGX.
>>>
>>> And the point of that is? That you still can cirumvent LSM for feeding
>>> executable code into SGX.
>>
>> How? LSM would see that you're trying to map a page RWX so you can do
>> your ioctl?
> 
> With plain mmap() + mprotect(), the LSM will prevent you from making memory that *was* writable executable.  This is by design and SELinux supports it.  I don’t remember the name of the associated SELinux permission off the top of my head.
> 
> If we start enforcing equivalent rules on SGX, then the current API will simply not allow enclaves to be loaded — no matter how you slice it, loading an enclave with the current API is indistinguishable from making arbitrary data executable.

Yes this is exactly what I intended here: a very simple change that
stops SGX from confusing LSM. Just by enforcing that everything that
looks like a memory write (EADD, EAUG, EDBGWR, etc.) actually requires
write permissions, reality and LSM should be on the same page.

If you want to go further and actually allow this behavior when your LSM
would otherwise prohibit it, presumably the same workarounds that exist
for JITs can be used for SGX.

--
Jethro Beekman | Fortanix