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:	Fri, 25 Apr 2008 15:38:34 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	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

Mathieu Desnoyers wrote:
> 
> DWARF2 is capable of extracting information only when not optimized away
> by the compiler. That's the whole point of markers : liveness is good in
> this case because we make sure the variable is there, not that it
> *might* be there. The latter case might be good enough for a debugger,
> but not for a production system tracer.
> 

That's what I address with the last paragraph of the email.

> 
> The builtin expect will take care to put the instructions out of the
> hot paths and therefore leave them out of the icache with gcc
> -freorder-blocks (in -O2). The only addition to the frequently used
> icache is, in this case, the 5 bytes jump, 2 bytes mov, 2 bytes test and
> 2 (or 6) bytes conditional branch, for a total of 11 bytes for small
> functions and 15 bytes for functions which require near jumps.
> 
>> Now, if a breakpoint is too expensive, one can do exactly the same trick 
>> with a naked call instruction, with a higher icache impact in the unused 
>> case (five bytes instead of one or two).  However, the key to low impact is 
>> to use the debugging information to recover state.
> 
> The runtime cost of function call is bigger than the jump. I don't see
> what this buys us.

You get zero instructions and five bytes of NOP in the non-taken case.

In the taken case, you move the whole thing out of line.

>> (Liveness at the probe point is still possible to enforce with this 
>> technique: give gcc a "g" read constraint as part of the probe instruction. 
>>  That makes gcc ensure the information is *somewhere*.  The debugging 
>> information will tell you where to pick it up from. Obviously, any time 
>> liveness is enforce you suffer a potential cost.)
> 
> It could be possible to do so. However, passing a variable argument list
> to a marker is rather more flexible than those inline assembly
> constraints. And you are still tied to the variable names and offer no
> abstraction between the kernel implementation and the conceptual name
> associated to a traced variable.

"Rather more flexible?"  Surely you're joking, Mr. Feynman?  There is no 
difference, none, nada.

Furthermore, your capture stub compiler, or trace data extractor, can do 
any kind of mapping it pleases; so I'm utterly confused what you're 
talking about "still tied to variable names."

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