linux-kernel - Re: [Patch 02/12] Introducing generic hardware breakpoint handler 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] [day] [month] [year] [list]

Date:	Tue, 26 May 2009 12:19:18 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Benjamin Herrenschmidt <benh@....ibm.com>,
	maneesh@...ux.vnet.ibm.com, Roland McGrath <roland@...hat.com>,
	Masami Hiramatsu <mhiramat@...hat.com>
Subject: Re: [Patch 02/12] Introducing generic hardware breakpoint handler
	interfaces

On Tue, May 26, 2009 at 08:52:52AM +0530, K.Prasad wrote:
> On Mon, May 25, 2009 at 08:36:36PM +0200, Frederic Weisbecker wrote:
> > On Sat, May 16, 2009 at 05:55:52AM +0530, K.Prasad wrote:
> > > This patch introduces the generic Hardware Breakpoint interfaces for both user
> > > and kernel space requests.
> > > 
> > > Original-patch-by: Alan Stern <stern@...land.harvard.edu>
> > > Signed-off-by: K.Prasad <prasad@...ux.vnet.ibm.com>
> > > Reviewed-by: Alan Stern <stern@...land.harvard.edu>
> > > ---
> > >  arch/Kconfig           |    4 
> > >  kernel/Makefile        |    1 
> > >  kernel/hw_breakpoint.c |  369 +++++++++++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 374 insertions(+)
> > > 
> > > +/**
> > > + * register_kernel_hw_breakpoint - register a hardware breakpoint for kernel space
> > > + * @bp: the breakpoint structure to register
> > > + *
> > > + * @bp.info->name or @bp.info->address, @bp.info->len, @bp.info->type and
> > > + * @bp->triggered must be set properly before invocation
> > > + *
> > > + */
> > > +int register_kernel_hw_breakpoint(struct hw_breakpoint *bp)
> > > +{
> > > +	int rc;
> > > +
> > > +	rc = arch_validate_hwbkpt_settings(bp, NULL);
> > > +	if (rc)
> > > +		return rc;
> > > +
> > > +	spin_lock_bh(&hw_breakpoint_lock);
> > > +
> > > +	rc = -EINVAL;
> > > +	/* Check if we are over-committing */
> > > +	if ((hbp_kernel_pos > 0) && (!hbp_user_refcount[hbp_kernel_pos-1])) {
> > 
> > 
> > 
> > If hbp_kernel_pos == 0, shouldn't it return -ENOSPC ?
> > If several kernel users try to register a breakpoint, and there is no
> > more room for one of them, then we know it has failed not because
> > of an error in the breakpoint instance but because of a lack of
> > resources.
> > 
> > Frederic.
> >
> 
> Agreed. It's done correctly in the case of register_user_hw_breakpoint()
> but not here. Here's a tiny patch that corrects it.


Thanks. I will apply this one too.

Frederic.


> 
>  
> Modify the return code in register_kernel_hw_breakpoint()
> 
> Modify the return code in register_kernel_hw_breakpoint() to return -ENOSPC
> if we are error-returning due to lack of free HW breakpoint registers.
> 
> Signed-off-by: K.Prasad <prasad@...ux.vnet.ibm.com>
> ---
>  kernel/hw_breakpoint.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6-tip.hbkpt/kernel/hw_breakpoint.c
> ===================================================================
> --- linux-2.6-tip.hbkpt.orig/kernel/hw_breakpoint.c
> +++ linux-2.6-tip.hbkpt/kernel/hw_breakpoint.c
> @@ -312,7 +312,7 @@ int register_kernel_hw_breakpoint(struct
>  
>  	spin_lock_bh(&hw_breakpoint_lock);
>  
> -	rc = -EINVAL;
> +	rc = -ENOSPC;
>  	/* Check if we are over-committing */
>  	if ((hbp_kernel_pos > 0) && (!hbp_user_refcount[hbp_kernel_pos-1])) {
>  		hbp_kernel_pos--;

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