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: <y0mk5p3qo8r.fsf@ton.toronto.redhat.com>
Date:	Wed, 31 Oct 2007 11:48:20 -0400
From:	fche@...hat.com (Frank Ch. Eigler)
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 ?

Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> writes:

> [...]  SystemTAP, for instance, does it out of tree by keeping a
> separate list of address where kprobes must be installed. It does
> the job on a distribution kernel maintainer perspective (Redhat),
> since they freeze to a particular kernel version and update this
> list every time it breaks, but will always be a source of
> frustration for vanilla kernel users and kernel developers.

This misstates the details.  What systemtap has out-of-tree is a list
of kernel function names (and parameter names), not addresses.  This
list does change somewhat with kernel versions, but we generally keep
up.  We do test with vanilla kernels, and several non-RH distributors
test with their kernels.  It is a problem, but it is manageable.


> I think the best way to follow the code flow is to add markup in the
> code itself: it would follow the kernel HEAD and let each subsystem
> maintainer identify the key instrumentation sites of their
> subsystem.

Of course - when and where the dormant overheads are acceptable, and
where the maintainers are willing to commit to a long-term interface
(marker name/arguments).  Systemtap can connect to markers as well as
to kprobes and other event sources: mix & match based on what's
available in your particular kernel and what data/computation you
want.


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


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