linux-kernel - Re: [PATCH] tracing: expose current->comm to kprobe events

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]

Date:	Fri, 3 Jun 2016 09:41:29 -0700
From:	Omar Sandoval <osandov@...ndov.com>
To:	Masami Hiramatsu <mhiramat@...nel.org>
Cc:	Namhyung Kim <namhyung@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>, kernel-team@...com,
	Omar Sandoval <osandov@...com>
Subject: Re: [PATCH] tracing: expose current->comm to kprobe events

On Fri, Jun 03, 2016 at 05:59:43PM +0900, Masami Hiramatsu wrote:
> On Fri, 3 Jun 2016 00:40:02 +0900
> Namhyung Kim <namhyung@...il.com> wrote:
> 
> > Hello,
> > 
> > On Wed, Jun 1, 2016 at 3:17 PM, Omar Sandoval <osandov@...ndov.com> wrote:
> > > From: Omar Sandoval <osandov@...com>
> > >
> > > ftrace is very quick to give up on saving the task command line (see
> > > `trace_save_cmdline()`). The workaround for events which really care
> > > about the command line is to explicitly assign it as part of the entry.
> > > However, this doesn't work for kprobe events, as there's no
> > > straightforward way to get access to current->comm. Add a kprobe event
> > > variable $comm which provides exactly that.
> 
> Hmm, would you already tried to trace task/task_newtask and task/task_rename
> events? which also gives you task's comm.
> Of course there are no way to get running task's comm...

Right, I was trying to figure out what task was hitting a specific code
path, so I don't think that would work.

> Anyway, I also think more generic idea, e.g. enable to get "current" address.
> With the "current" address, we can do similar thing (by using perf-probe)

Yeah, that would also be useful in general. I think having this is still
convenient for quick debugging.

> The code looks good to me. As Namhyung said, it should support uprobes
> too.

Yesterday I sent out v2 which also supports uprobes, let me know if you
didn't receive it.

> BTW, now I'm considering integrate kprobes and uprobes ftrace interface.
> It is easy to classify given event definition is for kprobes or uprobes.
> So, we don't need to have 2 different interfaces for it.
> 
> Thank you,

Thanks for taking a look.

-- 
Omar