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: <20060919210703.GD18646@redhat.com>
Date:	Tue, 19 Sep 2006 17:07:03 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	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 -

On Tue, Sep 19, 2006 at 04:28:02PM -0400, Mathieu Desnoyers wrote:

> [...]
> > In order to have what we appear to need, we cannot avoid having some
> > impact.  (Even NOPs have impact.)

> I am all for giving this decision to the end-user or the
> distribution which will configure the kernel. [...]

If the decision you're talking about is whether all markers in the
system should behave one way or another, then this is a degree of
central control that we have not contemplated during the entire
thread, until now.

It is an end-user such as an administrator who will figure out which
probes/markers/tracing elements need what kind of processing attached.
They don't want to recompile the kernel to switch.  They will want
different types of processing, or none at all, for different markers
during a system lifetime.

> * Users debugging servers will more likely want the kprobe or jprobe option.
> * Users interested in high performance tracing will want fprobe
> and/or jprobe.
> * Users interested in embedded systems will want to avoid tools
> outside the kernel that rely on module loading: their kernel often
> not even support modules. -> fprobe

This line of thinking makes me worry that we've forgotten all that we
learned during the weekend.  Amongst the insights apparently agreed
was that on *any given system*, a mixture of static an dynamic probing
was likely necessary.  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.

(Regarding module loading being considered a blocker for a tool like
systemtap, don't.  We will support pre-compiled boot-time
instrumentation loaded from e.g. initrd or linked right into vmlinux.)

> M. Bligh's idea is an interesting use of fprobes through modules
> that could make dynamic tracing more effective for accessing local
> variables. [...]

That's if it works, if it can be implemented, if it does not create
conflicts between multiple tracing/probing systems, if ...  

Yes, in theory it might bridge the gulf between compile-time and
run-time configuration, but aren't these all big "if"s right now?

> With or without his idea, the goal of this marker mechanism is to
> meet all those user's different needs.

I don't understand how this new compile-time configured style of
marker is to serve anyone who wants to use something other than a
single distribution-picked tracing/probing tool.  I though we had
abandoned that model some time ago.

- FChE

Content of type "application/pgp-signature" skipped