Re: [PATCH v2 3/3] x86/entry/64: Move #BP from IST to the IRQ stack

From: Andy Lutomirski
Date: Wed Jul 29 2015 - 13:57:51 EST


On Tue, Jul 28, 2015 at 2:54 AM, Borislav Petkov <bp@xxxxxxxxx> 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@xxxxxxxxxx>
>> ---
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/