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>] [day] [month] [year] [list]
Date:	Fri, 6 Jul 2007 16:48:59 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Roland McGrath <roland@...hat.com>
cc:	Prasanna S Panchamukhi <prasanna@...ibm.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] hwbkpt: Hardware breakpoints (was Kwatch)

On Wed, 27 Jun 2007, Roland McGrath wrote:

> In the first battle just to make it compile, the only issue was that you
> assume every machine has TIF_DEBUG, which is in fact an implementation
> detail chosen lately by i386 and x86_64.  AFAIK the only reason for it
> there is just to make a cheap test of multiple bits in the hot path
> deciding to call __switch_to_xtra.  Do you rely on it meaning something
> more precise than just being a shorthand for hw_breakpoint_info!=NULL?

Going over the code, I remembered that TIF_DEBUG really does mean moree
than just hw_breakpoint_info != NULL.  It means that the thread
actually has some breakpoints registered.

Why keep the hw_breakpoint_info structure if there are no registered 
breakpoints?  I did it so that the virtualized DR[0-3] values would 
remain intact.

For other processors that have only one debug register, this won't
matter so much.  But of course there are references to TIF_DEBUG in the 
arch-independent code.  Do you think there would be any problem about 
reserving a bit for TIF_DEBUG in the other architectures?

Alan Stern

P.S.: I'm just now getting around to doing the stuff we discussed last
week.  It has been a busy time...  At OLS somebody asked when 
hw-breakpoint would get into the mainline.  I guessed that it would be 
a few months before it is added to -mm.  Solving this 
pre/post-notification issue will be difficult.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ