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
