linux-kernel - Re: [PATCH 1/5] ftrace: use module notifier for function tracer

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: <alpine.DEB.2.00.0904200942350.15439@gandalf.stny.rr.com>
Date:	Mon, 20 Apr 2009 09:57:35 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Tim Abbott <tabbott@....edu>
Subject: Re: [PATCH 1/5] ftrace: use module notifier for function tracer



On Sun, 19 Apr 2009, Rusty Russell wrote:

> On Thu, 16 Apr 2009 11:48:31 am Steven Rostedt wrote:
> > From: Steven Rostedt <srostedt@...hat.com>
> > 
> > Impact: fix and clean up
> > 
> > The hooks in the module code for the function tracer must be called
> > before any of that module code runs. The function tracer hooks
> > modify the module (replacing calls to mcount to nops). If the code
> > is executed while the change occurs, then the CPU can take a GPF.
> > 
> > To handle the above with a bit of paranoia, I originally implemented
> > the hooks as calls directly from the module code.
> > 
> > After examining the notifier calls, it looks as though the start up
> > notify is called before any of the module's code is executed. This makes
> > the use of the notify safe with ftrace.
> 
> Hi Steven,
> 
>    Unfortunately not: we do parse_args, which can call into the module code.
> (Though it shouldn't do anything "significant", as it won't get a chance to
> clean up if module load fails later).
> 
> I think you need to do something else in general.  Share the module_mutex for
> the ftrace code?  The ksplice guys have a similar issue, so maybe we should
> generalize this into a "kernel_text" mutex?

Hi Rusty,

Thanks, for the update. I think we may still be OK.

The thing that dynamic ftrace must watch out for is not running of code 
per say, but the executing of code on one cpu that is being modified on 
another.

Can those parse_args kick off threads? Hmm, probably. Sounds nasty to 
me.

The other thing is, if the parse_args code is only in "__init" then they 
also will not be touched.

I guess we can keep the code as notify if we never expect to run kthreads 
from parse_args. Or is it possible to move parse_args after notify?

-- Steve

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