Messages in this thread | | | From | Andy Lutomirski <> | Subject | Re: [PATCH 1/7] x86/entry: Fix #UD vs WARN more | Date | Thu, 18 Jun 2020 12:29:50 -0700 |
| |
> On Jun 18, 2020, at 12:02 PM, Peter Zijlstra <peterz@infradead.org> wrote: > > On Thu, Jun 18, 2020 at 11:36:53AM -0700, Andy Lutomirski wrote: > >> I wasn't imagining going far down the rabbit hole at all -- I think >> that, at most, we should cover the path for when the fault wasn't a >> BUG/WARN in the first place. I admit that, for #UD in particular, >> this isn't a big deal, but if it were a different vector, this could >> matter. > > Right, so there's 3 cases for ud2: > > - WARN; ud2, bug_entry, recovers > - BUG; ud2, bug_entry, dies > - UBSAN; ud2, !bug_entry, dies
4. The #UD matches an extable entry. I don’t know whether this ever happens for real.
The failure is still a bit farfetched: we’d need an extable to hit in an inconsistent state where we blow up due to a lack of entry handling.
> > Nothing else should be generating ud2 instructions, any other #UD goes > into handle_invalid_op() -> do_error_trap() -> ... -> die(). > > [ while there, we should probably restructure do_trap() to have > cond_local_irq_enable() _after_ do_trap_no_signal(). ] > > We could probably change is_valid_bugaddr() to not use > probe_kernel_address(), because if it couldn't read the instruction, > we'd not be getting #UD in the first place. > > If we've gotten rid of probe_kernel_address() we can noinstr/inline that > and then we can only call into report_bug() IFF ud2. > > Does that make things 'better' ? This can only go realy bad if there's a > 1 byte instruction that triggers #UD, but I think that was ruled out. > > > --- > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > index c26751e303f1..275a621f1aff 100644 > --- a/arch/x86/kernel/traps.c > +++ b/arch/x86/kernel/traps.c > @@ -91,10 +91,7 @@ int is_valid_bugaddr(unsigned long addr) > if (addr < TASK_SIZE_MAX) > return 0; > > - if (probe_kernel_address((unsigned short *)addr, ud)) > - return 0; > - > - return ud == INSN_UD0 || ud == INSN_UD2; > + return *(unsigned short *)addr == INSN_UD2; > }
I’m okay with this, at least until we get PKRS or kernel XO memory. But probe_kernel_addr() would be wrong then, too. We need probe_kernel_text().
But I think you might need some IRQ fiddling. With your patch, a WARN with IRQs on will execute the printk code with IRQs off without lockstep handling, and an appropriately configured debugging kernel may get a recursive splat. Or if irq tracing somehow notices that IRQs got turned off, the warning recovery might return back to an IF=1 context with IRQs traced as off.
So maybe also do an untraced cond_local_irq_enable()? After all, if we’re trying to report a bug from IRQs on, it should be okay to have IRQs on while reporting it. It might even work better than having IRQs off.
> > static nokprobe_inline int > @@ -220,15 +217,17 @@ static noinstr bool handle_bug(struct pt_regs *regs) > { > bool handled = false; > > - /* > - * All lies, just get the WARN/BUG out. > - */ > - instrumentation_begin(); > - if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN) { > - regs->ip += LEN_UD2; > - handled = true; > + if (is_valid_bugaddr(regs->ip)) { > + /* > + * All lies, just get the WARN/BUG out. > + */ > + instrumentation_begin(); > + if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN) { > + regs->ip += LEN_UD2; > + handled = true; > + } > + instrumentation_end(); > } > - instrumentation_end(); > > return handled; > }
| |