linux-kernel - Re: [PATCH] Linux Markers 0.4 (+dynamic probe loader) for 2.6.17

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: <45123C7D.3080309@goop.org>
Date:	Thu, 21 Sep 2006 00:17:17 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	Martin Bligh <mbligh@...gle.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	prasanna@...ibm.com, Andrew Morton <akpm@...l.org>,
	Ingo Molnar <mingo@...e.hu>, Paul Mundt <lethal@...ux-sh.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jes Sorensen <jes@....com>, Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>, ltt-dev@...fik.org,
	systemtap@...rces.redhat.com, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] Linux Markers 0.4 (+dynamic probe loader) for 2.6.17

Mathieu Desnoyers wrote:
> Yup, good catch. I have not seen gcc removing this asm in my objdump however, by
> I guess we cannot be sure. This MARK_SYM() is only useful for kprobe
> insertion : I don't use it myself for the jump markup stuff. I don't know how
> relevant it is for kprobes users for the symbol to be at a specific location,
> as they don't know themself what data they are interested in and they simply
> don't want to modify the instruction stream. I fact, if the asm volatile
> modifies the instruction stream, it would be an unwanted side-effect :(
>   

"asm volatile" isn't documented to do anything other than prevent the 
asm from being removed altogether.  It doesn't prevent it from being 
moved elsewhere, and it doesn't imply any ordering dependency with the 
code around it.  So I don't think it will change the generated code, but 
I also don't think it will be all that useful unless there's something 
to actually make sure it's in a particular place - and that may change 
codegen because it may force the compiler to not eliminate/reorder/move 
the point at which you want the label.

Something like this might do it:

    #define MARK_SYM(label)						\
    	do {							\
    		__label__ here;					\
    	  here: asm volatile(#label " = %0" : : "m" (*&&here));	\
    	} while(0)

This at least gives the compiler a C-level label to hang the asm from.

> It doesn't matter :) You are absolutely right, they can get reordered, and the
> fact is : we don't care. The function above sets the *target_mark_call before
> the *target_mark_jump_over, so that the function pointer is set up before the
> jump can call it. But imagine the inverse : the will be able to the function
> call before the function call handler is set up. It really doesn't matter
> because the function pointer is always pointing to a valid function : either the
> "empty" default function or the inserted one.
>   

Does the local indirect jump really help?  Wouldn't you do just as well 
with the call?  It's a jump out of line, but if it points to the null 
function, it's likely to be in cache, and reducing the number of 
indirect targets within a few instructions will help the CPU keep its 
branch target prediction in order (modern Intel chips don't like having 
too many indirect jumps within a cache line, for example).

It's a pity you can't make these all direct jumps; I guess patching the 
instruction stream on an SMP system on the fly is too tricky...

(Though on x86 you could do something like make the default case 5 bytes 
of nops.  Then to patch it, you could patch in an int3 on the first 
byte, put the relative address in the other 4 bytes, then patch the int3 
back to the call/jump.  The int3 handler would look to see if the fault 
address is a kernel hook point, and if so, spin waiting for the *eip to 
go to a call/jump, then resume the instruction.)

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