linux-kernel - Re: [RFC Patch 6/9] Use virtual debug registers in process/thread handling code

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: <Pine.LNX.4.44L0.0810181123220.1469-100000@netrider.rowland.org>
Date:	Sat, 18 Oct 2008 11:34:56 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Roland McGrath <roland@...hat.com>
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 6/9] Use virtual debug registers in process/thread
 handling code

On Fri, 17 Oct 2008, Roland McGrath wrote:

> > There's a problem with moving the switch_to_thread_hw_breakpoint() call 
> > before current is updated. [...]
> 
> I got this.  I'm just saying let's look for ways to do this better.
> 
> Hmm.  The 64-bit version of __switch_to does the current change much
> earlier, before __switch_to_xtra and math_state_restore.  I wonder if the
> 32-bit version could change to match.  I can't see what in __switch_to_xtra
> would care either way, though I may be overlooking something.  Ingo?

Would it be better to move __switch_to_xtra down below the change to 
current, rather than moving the change to current up above 
__switch_to_xtra?

> If this does not change, then __switch_to_xtra can pass prev,next to
> switch_hw_breakpoint.  You can always do some slightly different
> bookkeeping in there to know that prev->next is the switch happening,
> so if there is a hit when current still == prev you can filter it out.

The cpu_hw_breakpoint structure would have to keep track of two tasks:  
the one whose breakpoints are currently loaded and the task that
preceded it.  When a breakpoint occurs and current is not equal to the
first task, we would skip clearing the user-breakpoint registers if
current was equal to the second.

But then what happens when the system alternates between running two 
tasks, one of which is being debugged and the other isn't?  The task 
not being debugged would constantly encounter breakpoints meant for the 
other task, because the breakpoint registers wouldn't get cleared.

Alan Stern

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