Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 29 Jul 2015 10:57:26 -0700 | Subject | Re: [PATCH v2 3/3] x86/entry/64: Move #BP from IST to the IRQ stack |
| |
On Tue, Jul 28, 2015 at 2:54 AM, Borislav Petkov <bp@alien8.de> wrote: > On Fri, Jul 24, 2015 at 10:57:06PM -0700, Andy Lutomirski wrote: >> There's nothing IST-worthy about #BP/int3. We don't allow kprobes >> in the small handful of places in the kernel that run at CPL0 with >> an invalid stack, and 32-bit kernels have used normal interrupt >> gates for #BP forever. >> >> Furthermore, we don't allow kprobes in places that have usergs while >> in kernel mode, so "paranoid" is also unnecessary. >> >> Signed-off-by: Andy Lutomirski <luto@kernel.org> >> --- >> arch/x86/entry/entry_64.S | 2 +- >> arch/x86/kernel/traps.c | 26 +++++++++++++------------- >> 2 files changed, 14 insertions(+), 14 deletions(-) > > ... > >> @@ -494,7 +494,15 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code) >> if (poke_int3_handler(regs)) >> return; >> >> + /* >> + * Use ist_enter despite the fact that we don't use an IST stack. >> + * We can be called from a kprobe in non-CONTEXT_KERNEL kernel >> + * mode or even during context tracking state changes. >> + * >> + * This means that we can't schedule. That's okay. >> + */ >> ist_enter(regs); > > Let's rename that thing. Call it atomic_ctxt_enter or whatever... >
OK if I do that as a follow-up? It would probably want to be a separate patch anyway.
Hmm, I'm starting to like this new regime in which we never ever switch to user mode from anywhere other than the standard kernel stack. It looks like even Xen may play along and do it cleanly soon :) Maybe I'll even add an assertion somewhere to make sure we don't break it. (I think this also means that the bad iret fixup can be simplified.)
Also, with all this stuff applied (and the modify_ldt thing, once the Xen folks figure out what's wrong), I think we can reinstate the old LARL check for 16-bit segments and thus prevent naughty users from banging on espfix using only sigreturn.
--Andy
| |