> On Dec 8, 2017, at 1:34 AM, Thomas Gleixner <t...@linutronix.de> wrote: > >> On Fri, 8 Dec 2017, Ingo Molnar wrote: >> * Andy Lutomirski <l...@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
