> On Dec 7, 2017, at 9:23 AM, Thomas Gleixner <t...@linutronix.de> wrote: > >> On Thu, 7 Dec 2017, Andy Lutomirski wrote: >> >>> On Thu, Dec 7, 2017 at 4:43 AM, Borislav Petkov <b...@alien8.de> wrote: >>>> On Wed, Dec 06, 2017 at 11:22:21PM -0800, Andy Lutomirski wrote: >>>> I think I like this approach. I also think it might be nice to move the >>>> whole cpu_entry_area into this new pgd range so that we can stop mucking >>>> around with the fixmap. >>> >>> Yeah, and also, I don't like the idea of sacrificing a whole PGD >>> only for the LDT crap which is optional, even. Frankly - and this >>> is just me - I'd make CONFIG_KERNEL_PAGE_TABLE_ISOLATION xor >>> CONFIG_MODIFY_LDT_SYSCALL and don't give a rat's *ss about the LDT. >> >> The PGD sacrifice doesn't bother me. Putting a writable LDT map at a >> constant address does bother me. We could probably get away with RO >> if we trapped and handled the nasty faults, but that could be very >> problematic. > > Where is the problem? You can map it RO into user space with the USER bit > cleared. The kernel knows how to access the real stuff.
Blows up when the CPU tries to set the accessed bit. > >> The version here: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pti&id=a74d1009ac72a1f04ec5bcd338a4bdbe170ab776 >> >> actually seems to work. > > The approach I've taken is to create a VMA and map it into user space with > the USER bit cleared. A little bit more effort code wise, but that avoids > all the page table muck and keeps it straight attached to the process. > > Will post once in a bit. 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. > > Thanks, > > tglx >
