linux-kernel - Re: [RFC Patch 2/9] 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.0810071122460.2591-100000@iolanthe.rowland.org>
Date:	Tue, 7 Oct 2008 11:36:30 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
cc:	linux-kernel@...r.kernel.org, Roland McGrath <roland@...hat.com>,
	<akpm@...ux-foundation.org>, <mingo@...e.hu>,
	<jason.wessel@...driver.com>, <avi@...ranet.com>,
	<richardj_moore@...ibm.com>
Subject: Re: [RFC Patch 2/9] x86 architecture implementation of Hardware
 Breakpoint interfaces

On Tue, 7 Oct 2008, K.Prasad wrote:

> This patch introduces two new files named hw_breakpoint.[ch] inside x86 specific
> directories. They contain functions which help validate and serve requests for 
> using Hardware Breakpoint registers on x86 processors.

> --- /dev/null
> +++ linux-bkpt-lkml-27-rc9/arch/x86/kernel/hw_breakpoint.c
> @@ -0,0 +1,684 @@

...
> +int pre_handler_allowed(unsigned type)
> +{
> +	if (type == HW_BREAKPOINT_EXECUTE)
> +		return 1;
> +	else
> +		return -EINVAL;
> +}

The routine's name should match the name in the header file.  "allowed" 
isn't right: You're _allowed_ to have pre_handlers -- they just won't 
get invoked.  "supported" would be better.

Also, the comment in the header file should explain the meaning of the
return value -- you should return 0 if a pre_handler is not supported, 
not -EINVAL.  Better yet, define the function (both here and in the 
header file) as returning bool rather than int.

> +
> +int post_handler_allowed(unsigned type)
> +{
> +	/* We can have a post handler for all types of breakpoints */
> +	return 1;
> +}

Same comments as above.

Also, in this initial version I would prefer to avoid the complications
of single-stepping.  It can always be added later.  So for now, the x86
implementation should not support post_handlers for execution
breakpoints.

...
> +/*
> + * Validate the arch-specific HW Breakpoint register settings
> + */
> +static int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
> +			unsigned long address, unsigned len, unsigned int type,
> +			unsigned int *align)

Why did you move this routine into the arch-specific code?

...
> +/*
> + * Handle debug exception notifications.
> + */
> +
> +static void switch_to_none_hw_breakpoint(void);
> +struct hw_breakpoint *last_hit_bp;
> +struct thread_hw_breakpoint *last_hit_thbi;

Shouldn't these variables be static?  Although if they're needed only for
single-stepping, they can be removed entirely for now...

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