linux-kernel - Re: [PATCH 4/6] ftrace, x86: make kernel text writable only for conversions

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.0902231044050.18221@gandalf.stny.rr.com>
Date:	Mon, 23 Feb 2009 10:51:21 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc:	Andi Kleen <andi@...stfloor.org>, 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>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	"H. Peter Anvin" <hpa@...or.com>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 4/6] ftrace, x86: make kernel text writable only for
 conversions

On Mon, 23 Feb 2009, Mathieu Desnoyers wrote:
> > 
> > As for RO_DATA and bugs, it is a very small window for this to happen, and 
> > the sys-admin is the one making the change. This is not some periodical 
> > update. The sys-admin must be the one to initiate the tracer to modify 
> > text, ie, enabling or disabling the function tracer. Which, by the way, is 
> > something a sys-admin should only do when the system is off line. The 
> > overhead of all functions being traced, would not be something to be 
> > doing on a production system, unless they need to analyze something going 
> > wrong.
> > 
> 
> The argument "not to be used on production systems" is incompatible with
> the LTTng view, sorry. If you design your code so it's usable only in
> debugging scenarios on development machines and not in the field, then I
> doubt LTTng will be able to rely on it. I'm OK with that, as long as
> nobody argue that such tracepoint could be replaced by the function
> tracer, because tracepoints has to be enabled in the field on production
> machines.

Please do not confuse ftrace with the function tracer. The stop_machine
is only about the function tracer and has nothing to do with the rest of
ftrace. This is one detail. Yes, tracing EVERY function in the kernel
will add an overhead. There's no way around it. It's OK to do it on a
production system, but it WILL add overhead. That's what happens when you
trace EVERY function.

Note, I leave a lot of the other tracers on by default, and those are all
within the noise of overhead. I'm only talking about the function tracer
that is meant to do a lot of tracing. Does LTTng trace EVERY function?

Now, yes, if you only select a few functions, there's no noticeable 
overhead. And yes then you would need to do the stop_machine anyway, and 
there will be a small window where the kernel text will be writable. 
Tracing only a small set of functions (say a few 100) is not much of an 
overhead, and I could see that being done on a production system.

> 
> I agree that the racy time window is not that large and is not really a
> security concern, but it's still just annoying.

Annoying? how so?

Again, the stop_machine part has nothing to do with DEBUG_RODATA, it is 
about the safest and easiest way to modify kernel text.

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