On Mon, Sep 29, 2014 at 2:37 PM, Thomas Gleixner <t...@linutronix.de> wrote: > On Mon, 29 Sep 2014, Andy Lutomirski wrote: >> On Mon, Sep 29, 2014 at 12:41 PM, Thomas Gleixner <t...@linutronix.de> wrote: >> > On Mon, 29 Sep 2014, Andy Lutomirski wrote: >> >> On Mon, Sep 29, 2014 at 11:59 AM, Thomas Gleixner <t...@linutronix.de> >> >> wrote: >> >> > On Mon, 29 Sep 2014, Andy Lutomirski wrote: >> >> >> Presumably interrupt delivery clears NT. I haven't spotted where >> >> >> that's >> >> >> documented yet. >> >> > >> >> > Nope, that's unrelated. >> >> >> >> If it weren't the case, then we'd be totally screwed. Fortunately, it >> >> is. I found it: SDM Volume 3 6.12.1.2 says: >> >> >> >> (On calls to exception and interrupt >> >> handlers, the processor also clears the VM, RF, and NT flags in the >> >> EFLAGS register, >> >> after they are saved on the stack.) >> > >> > Sorry, I misunderstood your question. >> > >> > And yes on exception and interrupt entry it is cleared. Otherwise the >> > whole feature would not work at all ... >> > >> > But that's why I'm really not worried about it. While we can mask out >> > the stupid bit easily, it does not provide any value except protecting >> > silly userspace from rightfully raised exceptions. >> > >> > When I first saw that patch, I was worried about the security impact, >> > but after staring long enough at the SDM and the code, the only way it >> > can explode is when returning to user space. It cannot explode in the >> > kernel. >> >> This is only true as long as the only use of lret from a system call >> (or kernel thread started from a system call) is to return to >> userspace. >> >> For example, __efi64_thunk uses lretq, so mixed-mode EFI doesn't >> violate this assumption, but __efi64_thunk could just as easily have >> used iret. > > And if __efi64_thunk would use iret, it would be wrong to begin with, > really. I'd rather see it die right there. > >> IOW, I don't think there's any vulnerability here, but this makes me >> nervous. > > I was pretty relaxed until you mentioned EFI ....
:) I have a patch that seems to work. It won't have any effect at all on syscall performance (32- or 64-bit), but it slows down sysenter by 15 cycles or so. On the other hand, if we did this, then we could possible stop saving and restoring RFLAGS in switch_to, which might be worthwhile, since 64-bit code ought to be more common than 32-bit these days. See also: https://lkml.org/lkml/2006/9/18/161 --Andy > > Thanks, > > tglx -- 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/
