On Fri, Jul 19, 2019 at 8:59 PM Eiichi Tsukata <de...@etsukata.com> wrote: > > > On 2019/07/19 5:27, Andy Lutomirski wrote: > > Hi all- > > > > I suspect that a bunch of the bugs you're all finding boil down to: > > > > - Nested debug exceptions could corrupt the outer exception's DR6. > > - Nested debug exceptions in which *both* exceptions came from the > > kernel were probably all kinds of buggy > > - Data breakpoints in bad places in the kernel were bad news > > > > Could you give this not-quite-finished series a try? > > > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/ > > > > Though I'm still trying to find out other cases(other areas which could > be buggy if we set hw breakpoints), as far as I tested, there is > no problem so far. > > If I understand correctly, the call trace and the dr6 value will be: > > ==== > > debug() // dr6: 0xffff4ff0, user_mode: 1 > TRACE_IRQS_OFF > arch_stack_user_walk() > debug() // dr6: 0xffff4ff1 == 0xffff4ff0 | 0xffff0ff1 ... (*) > do_debug() > WARN_ON_ONCE > do_debug() // dr6: 0xffff0ff0(cleared in the above do_debug())
The dr6 register will indeed be cleared like this, but the dr6 variable should still be 0xffff4ff0. > > (*) : > > * The Intel SDM says: > > * > > * Certain debug exceptions may clear bits 0-3. The remaining > > * contents of the DR6 register are never cleared by the > > * processor. To avoid confusion in identifying debug > > * exceptions, debug handlers should clear the register before > > * returning to the interrupted task. > > ==== > > Note: printk() in do_debug() can cause infinite loop(printk() -> > irq_disable() -> do_debug() -> printk() ...), so printk_deferred() > was preferable. > Shouldn't that be fixed with my patches? It should only be able to recurse two deep: do_debug() from user mode can indeed trip breakpoints, but the next do_debug() will clear DR7 in paranoid_entry.
