linux-kernel - Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17

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: <20060920132008.GF18646@redhat.com>
Date:	Wed, 20 Sep 2006 09:20:08 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Karim Yaghmour <karim@...rsys.com>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Douglas Niehaus <niehaus@...s.ku.edu>,
	Tom Zanussi <zanussi@...ibm.com>,
	Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	William Cohen <wcohen@...hat.com>,
	"Martin J. Bligh" <mbligh@...igh.org>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	systemtap@...rces.redhat.com, ltt-dev@...fik.org
Subject: Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17

Hi -

> > [...]  For the static part of the instrumentation, a
> > marker that could be hooked up to either type of probing system was
> > desirable, which implies some sort of run-time changeability.
> 
> Ok. So if I get what you're saying here, you'd like to be able to
> overload a marker? 

Sort of.  Remember, we discussed markers as *marking* places and
things, with the intent that they be decoupled from the actual
*action* that is taken when the marker is hit.

> Can you suggest a macro that can do what you'd like. [...]

Compare the kind of marker I showed at OLS and presently supported by
systemtap.  Its unparametrized version looks like this:

#define STAP_MARK(name) do { \
   static void (*__mark_##name##_)(); \
   if (unlikely (__mark_##name##_)) \
   (void) (__mark_##name##_()); \
} while (0)

A tracing/probing tool would hook up to a particular and specific
marker at run time by locating the __mark_NAME static variable (a
function pointer) in the data segment, for example using the ordinary
symbol table, and swapping into it the address of a compatible
back-end handler function.  When a particular tracing/probing session
ends, the function pointer is reset to null.

Note that this technique:

- operates at run time
- is portable
- in its parametrized variants, is type-safe
- does not require any future technology
- does impose some overhead even when a marker is not active

- FChE

Content of type "application/pgp-signature" skipped