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]

Date:   Fri, 19 Apr 2019 20:54:00 +0000
From:   Jethro Beekman <jethro@...tanix.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     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

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?

> No, we are not making special cases and exceptions for SGX.

Maybe I didn't express myself clearly? I don't think I was suggesting
anything like that.

--
Jethro Beekman | Fortanix