linux-kernel - Re: [RFC] Create kinst/ or ki/ directory ?

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: <20071031192940.GB12334@redhat.com>
Date:	Wed, 31 Oct 2007 15:29:40 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jeff Garzik <jeff@...zik.org>,
	Randy Dunlap <rdunlap@...otime.net>, hch@...radead.org,
	linux-kernel@...r.kernel.org, Sam Ravnborg <sam@...nborg.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Prasanna S Panchamukhi <prasanna@...ibm.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <pzijlstr@...hat.com>,
	Philippe Elie <phil.el@...adoo.fr>,
	"William L. Irwin" <wli@...omorphy.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Lameter <christoph@...eter.com>,
	Valdis.Kletnieks@...edu
Subject: Re: [RFC] Create kinst/ or ki/ directory ?

Hi -

On Wed, Oct 31, 2007 at 12:36:24PM -0400, Mathieu Desnoyers wrote:

> [...]  That's right, Systemtap uses symbols, thanks for the
> clarification. But my point is still valid: SystemTAP expects
> function names and argument names to stay unchanged, therefore using
> the kernel code itself as an API to userspace tools. [...]

To be precise, this applies *kprobes*-based probes only.  In
acceptance of this fragility, systemtap includes constructs (aliases,
version-dependent conditionals) to make it reasonably easy to adapt to
different kernel versions.

> I think that SystemTAP's [kprobes-based probes'] flexibility is
> great, but leads to fagileness wrt kernel code changes. If the "core
> events" required by SystemTAP (and also by LTTng by the way) could
> be turned into markers, I think it would gain in robustness.

Yes.

> Providing the ability to instrument code locations with breakpoints, in
> addition to this, will help users unsatisfied with the information
> they have, unwilling to recompile their kernel or modules with their
> own markers, ready to accept the two limitations :
> - performance hit of a breakpoint
> - unability to access variables within optimized functions

That latter point has been repeatedly overstated.  Markers provides a
fixed set of values.  kprobes/dwarf provides access to any statements
and any values (including locals) that a compiler did not altogether
elide.  While the latter set is by its nature variable, it will be
much bigger than anything a reasonable set of markers will ever
expose.

> So yes, both approaches seems to be complementary.

Indeed.

> > > About extending on ptrace, I am sorry to say that this solution has
> > > the same downsides as kprobes: it is too slow for high performance
> > > applications, especially if turned on system-wide. [...]
> > 
> > Roland McGrath's ptrace-replacement (utrace) should help with this.
> 
> Yes, I think he did a good job at it. However, it is not a replacement
> for the markers [...]

Right, not as a whole, but it *could* be an alternative way to hook
into system call type events.

> [...]
> So I would say : I'll try to submit a core set of markers patches for
> review on LKML and see what people have to say.

Thank you.  Our team is already in contact to help.

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