linux-kernel - Re: [RFC] [PATCH 4/7] Uprobes Implementation

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:	Tue, 12 Jan 2010 06:36:00 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	utrace-devel <utrace-devel@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Maneesh Soni <maneesh@...ibm.com>,
	Jim Keniston <jkenisto@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH 4/7] Uprobes Implementation

On Mon, Jan 11, 2010 at 05:55:53PM +0530, Srikar Dronamraju wrote:
> +static const struct utrace_engine_ops uprobe_utrace_ops = {
> +	.report_quiesce = uprobe_report_quiesce,
> +	.report_signal = uprobe_report_signal,
> +	.report_exit = uprobe_report_exit,
> +	.report_clone = uprobe_report_clone,
> +	.report_exec = uprobe_report_exec
> +};

So, as stated before, uprobe seems to handle too much standalone
policies such as freeing on exec, always inherit on clone and never
on fork. Such rules should be decided from uprobe clients not
from uprobe itself and that makes it not enough flexible to
be usable for now.

For example if we want it to be usable by perf, we have two ways:

- a trace event. Unfortunately, like I explained in a previous
  mail, this doesn't seem to be a suitable interface for this
  particular case.

- a performance monitoring unit, with the existing unified interface
  struct pmu, usable by perf.

Typically, to use it with perf toward a pmu, perf tools need to
create a uprobe on perf process and activate its hook on the next exec.
Thereafter, it's up to perf to decide if we inherit through clone
and fork.

Here I fear utrace and perf are going to collide.

See how could be the final struct pmu (we need to extend it
to support utrace):

struct pmu {
	enable() -> called we schedule in a context where we want
                    a uprobe to be active. Called very often
        disable() -> the above opposite

        /* Not yet existing callbacks */

        hook_task() -> called when a process is created which
                       we want to activate our hook
                       would be typically called once on
                       exec if we have set enable_on_exec
                       and also on clone()/fork()
                       if we want to inherit.
}

The above hook_task (could be divided in more precise callback events
like hook_on_exec, hook_on_clone, etc...) would be needed by perf
to drive correctly utrace and this is going to collide with utrace
callbacks that notify execs and forks.

Probably utrace can be kept for all the utrace breakpoint signal
handling an so. But I guess the rest can be implemented on top
of a struct pmu and driven by perf like we did with hardware
breakpoints re-implementation.

Just an idea.

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