On Fri, Mar 27, 2015 at 1:09 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Fri, Mar 27, 2015 at 11:37 AM, Andy Lutomirski <l...@amacapital.net> wrote: >> >> User does sysenter. We end up in native_irq_enable_sysexit. We do: >> >> swapgs >> sti >> >> <-- NMI here can happen on some (all?) cpus, returns successfully >> *with interrupts unmasked* > > I think AMD documented that the sti "interrupt shadow" shadows even > NMI. And for Intel, it definitely does not (but "mov ss" and "pop ss" > masks even NMI for the next instruction - so the interrupt shadow is > different for these cases). > > That said, it wasn't 100% clear that the "NMI return to immediate > regular interrupt" can actually happen even on Intel. Iirc, there was > some discussion about when the CPU actually tests the IRQ line after > an 'iret'. It might end up testing the IF only after executing the > instruction it returns to, so it's possible that the sequence > > .. interrupts disabled .. > sti > sysexit > > can not be interrupted by regular interrupts between the 'sti' and the > 'sysexit' even if an NMI were to have happened between the two. > >> My preferred fix would be to use sysretl instead of sysexit. As far >> as I know, there are no 64-bit CPUs at all that don't support sysretl. > > That 'sti+sysexit" is used for the native 32-bit case too, not just > the compat mode for x86-64. So I don't necessarily disagree with using > sysretl, but..
Does it matter on 32-bit kernels? There's no swapgs, so IRQs should still be safe, and we have a real stack pointer before sysexit. --Andy > > Linus -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
