Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy

[Jeff Merkey]

On 12/14/15, Jeff Merkey <linux.mdb@xxxxxxxxx> wrote:
> On 12/14/15, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>>
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>> Q: What is the most annoying thing in e-mail?
>>
>> * Jeff Merkey <linux.mdb@xxxxxxxxx> wrote:
>>
>>> I trigger it by writing to the dr7 and dr1, 2, 3 or four register and
>>> set an execute breakpoint without going through
>>> arch_install_hw_breakpoint.  When the breakpoint fires, the system
>>> crashes and hangs on the processor stuck in an endless loop inside the
>>> int1 handler in hw_breakpoint.c --
>>
>> What is still not clear to me, can you trigger the hang not via some
>> special
>>
>> kernel driver that goes outside regular APIs and messes with the state of
>> the
>> debug registers, but via the proper access methods, i.e. various
>> user-space
>> ABIs?
>>
>> Thanks,
>>
>> 	Ingo
>>
>
> Any process that can get access to the debug registers can trigger
> this condition.  As it stands, if restricted to the established API in
> hw_breakpoint.c this bug should not occur unless someone triggers an
> errant breakpoint.  That being said, there is a severe bug in the code
> path if for some reason an application triggers a breakpoint exception
> and no event has been registered, the system will crash with no logged
> output of any kind indicating why it happened.  It's not severe enough
> for a panic but does need to be handled gracefully just as exception
> handling 101.
>
> Sorry about the top posting.  I forget sometimes.
>
> Jeff
>

What's more problematic is that debuggers MUST zero dr7 upon entry
then restore it to prevent breakpoints while inside a debugger
console.  kgdb/kdb both fiddle with dr7 directly and bypass the API in
many cases.  Any kernel module can trigger a breakpoint including
userspace debuggers.  Most of these cases are handled at the bottom of
do_debug and in the perf handlers.  The problem here is that the
normal handling in do_debug gets short circuited when this bug gets
hit that causes the system to get stuck in an endless interrupt cycle
with int1 firing off at the same address because the resume flag never
gets set.

The v2 patch fixes the bug, prints a message.  Disabling the
breakpoint in dr7 is also worrisome since bp can be null in this code
path, but when that happens there is a singaling via the
thread.debugreg6 variable that keeps the system from locking up unless
you trigger a breakpoint outside the API (which kgdb/kdb do in some
cases, though they seem to keep a "dummy" bp registered while they
fiddle with dr7).

Jeff
--
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/