linux-kernel - Re: MARKER mechanism, try 2

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:	Mon, 18 Sep 2006 13:47:42 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"Frank Ch. Eigler" <fche@...hat.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jes Sorensen <jes@....com>, Andrew Morton <akpm@...l.org>,
	Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>,
	"Martin J. Bligh" <mbligh@...igh.org>
Subject: Re: MARKER mechanism, try 2

* Ingo Molnar (mingo@...e.hu) wrote:
> 
> * Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:
> 
> > It supports 5 modes :
> > 
> > - marker becomes nothing
> > - marker calls printk
> > - marker calls a tracer
> > - marker puts a symbol (for kprobe)
> > - marker puts a symbol and 5 NOPS for a jump probe.
> 
> just go for 'nothing' and the 5-NOP variant, and please implement 
> support for it from within LTT, via a kprobe - if you want me to support 
> this stuff for upstream inclusion. If we support any static tracer mode 
> and LTT does not support the kprobe mode then we are back to square 1 
> wrt. dependencies ...
> 

I am open to make LTTng support kprobes as a commodity (in fact, this point has
been on the LTTng project roadmap for almost a year). But in no way does it
solve the entire tracing problem. As an example, LTTng traces the page fault
handler, when kprobes just can't instrument it.

I keep thinking that a complete marker mechanism must have the ability to be
turned into function calls or inline functions when necessary.

Going further, we could think of a marker mechanism that would be aware of the
"difficulty" level of the probe, so that even if CONFIG_KPROBELOG is selected,
it would use a direct call or inlined function for probing the page fault
handler.

i.e. :

"normal" (nothing, kprobe, jumpprobe, printk or tracer)
MARK(eventname, "%d %s", myint, mystring);

"cannot be probed dynamically" (used in kprobes itself, page fault handler)
                               (only nothing or tracer)
MARK_NOPROBE(eventname, "%d %s", myint, mystring);

"cannot use printk" (used in scheduler, NMIs, wakeup, printk itself)
                    (nothing, kprobe, jumpprobe or tracer)
MARK_NOPRINT(eventname, "%d %s", myint, mystring);

Using the following table to select the mechanism :

Config/probe declaration     |   normal      |    noprobe    |     noprint
------------------------------------------------------------------------------
nothing                      |   nothing      |   nothing     |    nothing
kprobe                       |   kprobe       |   tracer      |    kprobe
jumpprobe                    |   jumpprobe    |   tracer      |    jumpprobe
printk                       |   printk       |   tracer      |    kprobe
tracer                       |   tracer       |   tracer      |    tracer

Therefore, selecting the "kprobe" configuration option would still let people
instrument the hardest paths while having mostly dynamic probes.

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 
-
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/