linux-ext4 - Re: [PATCH 1/1] x86: fix text

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:	Mon, 28 Apr 2008 22:21:30 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	Jiri Slaby <jirislaby@...il.com>,
	David Miller <davem@...emloft.net>, zdenek.kabelac@...il.com,
	rjw@...k.pl, paulmck@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
	linux-ext4@...r.kernel.org, herbert@...dor.apana.org.au,
	penberg@...helsinki.fi, clameter@....com,
	linux-kernel@...r.kernel.org, pageexec@...email.hu,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH 1/1] x86: fix text_poke


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> I'd much rather see something truly generic that doesn't need any 
> pre-inserted "markers" at all that disable optimizations, and that 
> allows just about anything. Including live system bug-fixes etc 
> (imagine finding a bug - and not at somethign that was previously 
> already "marked" - and just replacing the buggy function with a 
> non-buggy one).

Ob'plug: with the pending dyn-ftrace function tracer feature we do 
something rather close to that already: we have a 5 byte NOP in the 
prologue of every function that can be used as a non-destructive 'branch 
away' place.

Right now we use that to trace a (regex-ish pattern identified) set of 
functions. The regex pattern can be configured runtime via 
/debug/tracing/function_filter is not parsed runtime in any fastpath - 
it is used to activate/deactivate the tracepoints and patches them from 
NOPs into CALLs.

_But_ the same mechanism could perhaps be used to patch the function as 
well.

The cost is +5 bytes of NOP for every function in the system, but in 
practice we've not been able to measure any actual runtime costs of 
these NOPs - neither in micro-benchmarks nor in macro-benchmarks. (the 
only real cost here is the +5 bytes of I$ cost - otherwise the NOP will 
just be skipped by the decoder.)

the patching of these NOPs is inherently safe because they are inserted 
at build time. There's no negative impact to gcc optimizations at all. 
We get a nice selection of 75,000 tracepoints in an allmodconfig kernel 
- without _any_ source code level impact in the functions.

On the other hand, i'm not opposed to a handful of static markers either 
- i think the best model is to have both of these facilities. There are 
a couple of 'core events' that are not expressed via function calls, and 
even where they are expressed via function calls the function call 
layout is not stable while markers are stable across kernel versions. 
The notion of "a context-switch happened from task X to task Y" or "task 
X woke up task Y" is not going to change anytime soon so i'm not opposed 
to exposing that kind of information. And once we accept the static 
markers, we might as well make them as cheap as possible.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html