On Tue, Jul 21, 2015 at 7:53 PM, Brian Gerst <brgerst@xxxxxxxxx> wrote: > On Tue, Jul 21, 2015 at 10:12 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Tue, Jul 21, 2015 at 7:01 PM, Brian Gerst <brgerst@xxxxxxxxx> wrote: >>> On Tue, Jul 21, 2015 at 3:59 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: >>>> modify_ldt has questionable locking and does not synchronize >>>> threads. Improve it: redesign the locking and synchronize all >>>> threads' LDTs using an IPI on all modifications. >>> >>> What does this fix? I can see sending an IPI if the LDT is >>> reallocated, but on every update seems unnecessary. >>> >> >> It prevents nastiness in which you're in user mode with an impossible >> CS or SS, resulting in potentially interesting artifacts in >> interrupts, NMIs, etc. > > By impossible, do you mean a partially updated descriptor when the > interrupt occurs? Would making sure that the descriptor is atomically > updated (using set_64bit()) fix that? > I tried to exploit that once and didn't get very far. If I could cause the LDT to be populated one bit at a time, I think I could materialize a call gate out of thin air. The docs are unclear on what, if anything, the memory ordering rules are. I'm more concerned about the case where a segment register caches a value that is no longer in the LDT. If it's DS, ES, FS, or GS, it results in nondeterministic behavior but is otherwise not a big deal. If it's CS or SS, then an interrupt or exception will write a stack frame with the selectors but IRET can fault. If the interrupt is an NMI and certain other conditions are met and your kernel is older than 4.2-rc3, then you should read the CVE-2015-5157 advisory I'll send tomorrow :) Even on 4.2-rc3, the NMI code still struggles a bit if this happens. With this patch, you can never be in user mode with CS or SS selectors that point at the LDT but don't match the LDT. That makes me a lot more comfortable with modify_ldt. --Andy -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html