linux-kernel - Re: [RFC Patch 3/9] Modifying generic debug exception to use virtual debug registers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20081016192247.20F831542DA@magilla.localdomain>
Date:	Thu, 16 Oct 2008 12:22:47 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	prasad@...ux.vnet.ibm.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	<akpm@...ux-foundation.org>, <mingo@...e.hu>,
	<jason.wessel@...driver.com>, <avi@...ranet.com>,
	<richardj_moore@...ibm.com>
Subject: Re: [RFC Patch 3/9] Modifying generic debug exception to use virtual
 debug registers

> > I'm not sure you should change vdr6 when notify_die returns NOTIFY_STOP.
> > Maybe Alan and I hashed out the logic of this before, I don't recall.
> > If the notifier is eating the event, then it should not affect the
> > thread-virtualized view of %db6.  That would be consistent with the
> > existing code, where ->thread.debugreg6 is only set later when all the
> > intercepted or spurious exceptions have been filtered out.
> 
> I think we have to leave the code as it is.  As each notifier routine 
> processes the event, it will turn off the corresponding bits in vdr6.  
> We don't want those bits to get turned back on again by overwriting 
> vdr6 after the notifier chain has finished.

Ah, I now almost remember discussing this before.  We went around with the
notifier getting a pointer to "condition" to clear its bits, etc.  So there
is a special requirement for DIE_DEBUG notifiers to fiddle the vdr6 bits.
That ought to be documented somewhere or other, as well as clearly
commented in do_debug itself.

And what does it mean exactly?  The bits that should be left in thread.vdr6
are the virtualized bits, not the raw hardware bits.  That is, the low four
bits might need to be reordered from the actual hardware order.

And what about this scenario?

1. do_debug hits for %db3, being used for a ptrace user watchpoint
   -> vdr6 = hardware %db6 = 0x...08
   -> send SIGTRAP
2. do_debug hits for %db0, being used for an in-kernel hw_breakpoint
   -> hardware clears the low four bits before setting one of them
   -> vdr6 = hardware %db6 = 0x...01
   -> vdr6 &= ~1 = 0x...00
   -> run hw_breakpoint callback
3. try to return to user, deliver SIGTRAP to ptrace'ing debugger
4. debugger does PTRACE_PEEKUSR u_debugreg[6]
   -> read vdr6 = 0x...00
   -> wtf? where is my db3 hit?

To get this scenario correct, the virtual db6 bits for ptrace need to
remain set when there is a later do_debug that ptrace won't see.


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/