linux-kernel - Re: [patch 11/11] ftrace plugin for kernel symbol tracing using HW 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]

Date:	Thu, 5 Mar 2009 18:45:38 +0530
From:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Roland McGrath <roland@...hat.com>
Subject: Re: [patch 11/11] ftrace plugin for kernel symbol tracing using HW
	Breakpoint interfaces

On Thu, Mar 05, 2009 at 10:16:11AM +0100, Ingo Molnar wrote:
> 
> * Frederic Weisbecker <fweisbec@...il.com> wrote:
> 
> > On Thu, Mar 05, 2009 at 10:13:33AM +0530, prasad@...ux.vnet.ibm.com wrote:
> > > This patch adds an ftrace plugin to detect and profile memory access over
> > > kernel variables. It uses HW Breakpoint interfaces to 'watch memory
> > > addresses.
> > > 
> > > Signed-off-by: K.Prasad <prasad@...ux.vnet.ibm.com> 
> > > ---
> > 
> > 
> > Hi,
> > 
> > Nice feature. And moreover the standardized hardware 
> > breakpoints could be helpful for tracing.
> 
> yeah. The feature is much more alive now.
> 
> > Just some comments below.
> 
> One other thing:
> 
> +#ifdef CONFIG_FTRACE_SELFTEST
> +int trace_selftest_startup_ksym(struct tracer *trace, struct trace_array *tr)
> +{
> +       /* TODO: Will be implemented later */
> +       return 0;
> +}
> +#endif /* CONFIG_FTRACE_SELFTEST */
> 
> This needs to be implemented before i can pick the code up into 
> tip:tracing, as otherwise we will not notice it fast enough if 
> some of this stuff breaks.
> 
> Basically the ftrace plugin will be the main usage vector of 
> this facility, so the self-test is a must-have.
> 
> Looks very nice otherwise.
> 
> 	Ingo

Thanks for the comments.

Test-cases for the hardware breakpoint interfaces can be the following:

- Basic sanity test to check if the API is intact
- Perform various types of memory accesses, like read, write (I/O and 
  others when implemented) on a dummy kernel variable and verify the 
  trigger of the exception handler.

While the above can be a part of trace_selftest_startup_ksym(),
rigorous testing would involve:

i) stressing the HW breakpoint infrastructure to confirm sane behaviour
when interoperated with other users of a)breakpoint register b)the
do_debug() exception. This will involve simultaneous use of kprobes,
hardware breakpoint interface and requests from user-space (say through
GDB).
ii) Verifying successful HB_NUM number of register_ requests.
iii) Verifying right priority resolution, and handling user-space
requests.

These, in my opinion, would better fit in a full-featured test-suite
such as LTP, as opposed to startup testing in ftrace.

I will implement trace_selftest_startup_ksym() to contain the first two
test-cases in the next iteration of this code.

Thanks,
K.Prasad


Thanks,
K.Prasad


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