On Fri, Oct 16, 2015 at 2:32 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Fri, Oct 16, 2015 at 11:22 AM, Brian Gerst <brgerst@xxxxxxxxx> wrote: >> On Fri, Oct 16, 2015 at 1:34 PM, Borislav Petkov <bp@xxxxxxxxx> wrote: >>> On Fri, Oct 16, 2015 at 08:59:23AM -0700, Andy Lutomirski wrote: >>>> Wow I am incompetent. >>> >>> Bah, it can happen to anyone... >>> >>>> set_system_trap_gate(IA32_SYSCALL_VECTOR, entry_INT80_32); >>>> >>>> How did I not catch that in testing? Can you change that to >>>> set_system_intr_gate and see if that helps? >>> >>> Yeah, that was it. Well spotted, thanks! >> >> The INT80 handler doesn't do anything that requires interrupts to be >> off (it is already on the process stack), so the tracing should be >> fixed to expect interrupts on. do_int80_syscall_32() can be eliminated >> too. > > Good point. Then we blow up in potentially interesting ways if an > iopl-using process does int80 with interrupts off. Oh well. The code this replaced ran with interrupts enabled too, so I don't see this as a regression. Usermode drivers could already blow up the system in many different ways. I doubt there were any that actually did a system call while interrupts were disabled. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|