Re: [PATCH] x86: Implement __WARN using UD0

From: Peter Zijlstra
Date: Fri Feb 24 2017 - 06:44:17 EST


On Fri, Feb 24, 2017 at 01:53:27AM -0800, H. Peter Anvin wrote:
> On 02/24/17 01:15, Ingo Molnar wrote:
> >
> > * hpa@xxxxxxxxx <hpa@xxxxxxxxx> wrote:
> >
> >> Incidentally, as an alternative to a #UD, int $9 could be an alternative
> >> (exception vector 9 was discontinued with the 486.)
> >
> > With thousands of call sites a one byte opcode would be preferred, that's why INT3
> > is so nice.
> >
>
> Yes, but using INT3 would bugger up debuggers.

So I've been looking into this, in general debuggers will refuse to poke
INT3 on top of INT3 (sane and obvious behaviour).

Also, we'd run any actual handlers before fixup_bug(), the only thing
here is that we need to also do fixup_bug() if the instruction pointer
isn't changed. This would allow debuggers to effectively stack on top
of the already present breakpoint.

Optimized kprobes will make sure to not clobber INT3 (although it will
happily clobber anything else from __ex_table[]).

The only other point is that currently report_bug() relies on
is_valid_bugaddr() to tell if the instruction is 'good', but then
reports a BUG if there is no entry in __bug_table[]. We'd have to change
that to be strict and assume __bug_table[] is complete, and report
BUG_TRAP_TYPE_NONE when there is no __bug_table[] entry, this would also
avoid the need for is_valid_bugaddr().

So yes, its tricky but it could be done. A new single byte #UD
instruction would be much nicer though.