[lkml]   [2019]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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
 \ /
  Last update: 2019-04-19 22:55    [W:0.275 / U:3.724 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site