Messages in this thread | | | Subject | Re: [PATCH] LDT improvements | From | Andy Lutomirski <> | Date | Fri, 8 Dec 2017 05:20:00 -0800 |
| |
> On Dec 8, 2017, at 1:34 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > >> On Fri, 8 Dec 2017, Ingo Molnar wrote: >> * Andy Lutomirski <luto@amacapital.net> wrote: >>> I don't love mucking with user address space. I'm also quite nervous about >>> putting it in our near anything that could pass an access_ok check, since we're >>> totally screwed if the bad guys can figure out how to write to it. >> >> Hm, robustness of the LDT address wrt. access_ok() is a valid concern. >> >> Can we have vmas with high addresses, in the vmalloc space for example? >> IIRC the GPU code has precedents in that area. >> >> Since this is x86-64, limitation of the vmalloc() space is not an issue. >> >> I like Thomas's solution: >> >> - have the LDT in a regular mmap space vma (hence per process ASLR randomized), >> but with the system bit set. >> >> - That would be an advantage even for non-PTI kernels, because mmap() is probably >> more randomized than kmalloc(). > > Randomization is pointless as long as you can get the LDT address in user > space, i.e. w/o UMIP.
You only get the LDT selector, not the address.
> >> - It would also be a cleaner approach all around, and would avoid the fixmap >> complications and the scheduler muckery. > > The error code of such an access is always 0x03. So I added a special > handler, which checks whether the address is in the LDT map range and > verifies that the access bit in the descriptor is 0. If that's the case it > sets it and returns. If not, the thing dies. That works.
What if you are in kernel mode and try to return to a context with SS or CS pointing to a non-accessed segment? Or what if you try to schedule to a context with fs or, worse, gs pointing to such a segment?
> > Thanks, > > tglx
| |