linux-kernel - Re: [patch 02/11] x86 architecture implementation of Hardware Breakpoint interfaces

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.0903130959400.2898-100000@iolanthe.rowland.org>
Date:	Fri, 13 Mar 2009 10:04:44 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Roland McGrath <roland@...hat.com>, <prasad@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 02/11] x86 architecture implementation of Hardware
 Breakpoint interfaces

On Fri, 13 Mar 2009, Ingo Molnar wrote:

> The core issue being discussed is the debug register allocation 
> and scheduling model though, and you have not directly commented 
> on that.
> 
> My argument in a nutshell is that a bottom-up for user + 
> top-down for kernel use static allocator with no dynamic 
> scheduling will get us most of the benefits with a tenth of the 
> complexity.

Take this even farther: We shouldn't restrict userspace to bottom-up
register allocation.  With very little additional effort we can
virtualize the debug registers; then userspace can allocate them in
whatever order it wants and still end up using the physical registers
in bottom-up order (or top-down, which is the order used by the current
patches).

After all, there's nothing to prevent programs other than gdb from 
using ptrace, and there's no guarantee that gdb will continue to 
allocate registers in increasing order.

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/