linux-kernel - Re: malloc() tracing in perf?

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] [day] [month] [year] [list]

Message-ID: <20090806141744.GG18768@redhat.com>
Date:	Thu, 6 Aug 2009 10:17:44 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Pekka Enberg <penberg@...helsinki.fi>, Ingo Molnar <mingo@...e.hu>,
	acme <acme@...hat.com>, Steven Rostedt <rostedt@...dmis.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Eduard-Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
	roland <roland@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org
Subject: Re: malloc() tracing in perf?

Hi -

On Thu, Aug 06, 2009 at 02:59:34PM +0200, Peter Zijlstra wrote:

> [...]  Yeah in plain sight where nobody looks, really I thought the
> idea was to get utrace upstream, this means posting to
> linux-kernel. Going on LKML posts [...]

I don't wish to get into arguing about how much lkml posting is
appropriate, or to editorialize about what happened when some of this
code did actually get posted.  I'm simply discussing the technology.
It's never been hard to find.


> [...]
> Does this also iterate the already existing tasks to find if it was
> already mmap()ed?

Yes.

> > This overview skims over issues related to return probes, tracing
> > buffer manipulations, and much other stuff.
> 
> Right, so you basically read the (dwarf2) debug info for a particular
> lib/symbol and generate a kernel module that knows about that and then
> insert that into the kernel to act as a uprobe handler?

Yes.

> Uprobe will then do the code rewrite on mmap() time to insert a trap
> much like kprobe does? What if its a JITed code section and the JIT
> rewrites it? Will uprobes detect that?

You mean if the uprobe is made to refer to code that was created by a
JIT?  That does not happen in the preceding scenario, since the
uprobes addresses were based on prior generated debugging data.

Putting uprobes into JIT code such as LLVM or JVM code is something
for the future.


> > All the code for this is hidden in plain sight in every systemtap
> > release, so please feel free to refer to that and/or ask more detailed
> > questions.
> 
> I thought the goal was to get stuff upstream, but if you want to
> continue living in la-la land and not bother with upstream Linux then so
> be it I guess :-(

It's not that simple, and you know it.


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