linux-kernel - Re: Re: [tip:perf/kprobes] kprobes: Introduce NOKPROBE_SYMBOL() macro to maintain kprobes blacklist

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: <536A16A6.5040709@hitachi.com>
Date:	Wed, 07 May 2014 20:19:02 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Tony Luck <tony.luck@...il.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Rusty Russell <rusty@...tcorp.com.au>, rdunlap@...radead.org,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Arnd Bergmann <arnd@...db.de>, dl9pf@....de,
	Andrew Morton <akpm@...ux-foundation.org>, sparse@...isli.org,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	anil.s.keshavamurthy@...el.com,
	"David S. Miller" <davem@...emloft.net>,
	"ananth@...ibm.com" <ananth@...ibm.com>,
	Chris Wright <chrisw@...s-sol.org>, akataria@...are.com,
	linux-tip-commits@...r.kernel.org,
	"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>
Subject: Re: Re: [tip:perf/kprobes] kprobes: Introduce NOKPROBE_SYMBOL()
 macro to maintain kprobes blacklist

(2014/05/06 19:03), Masami Hiramatsu wrote:
> (2014/05/06 5:48), Tony Luck wrote:
>> This patch is in linux-next ("next-20140505") and I see a
>> bunch of "Failed to find blacklist" messages when booting
>> on ia64:
>>
>> Failed to find blacklist 0001013168300000
>> Failed to find blacklist 0001013000f0a000
>> Failed to find blacklist 000101315f70a000
>> Failed to find blacklist 000101324c80a000
>> Failed to find blacklist 0001013063f0a000
>> Failed to find blacklist 000101327800a000
>> Failed to find blacklist 0001013277f0a000
>> Failed to find blacklist 000101315a70a000
>> Failed to find blacklist 0001013277e0a000
>> Failed to find blacklist 000101305a20a000
>> Failed to find blacklist 0001013277d0a000
>> Failed to find blacklist 00010130bdc0a000
>> Failed to find blacklist 00010130dc20a000
>> Failed to find blacklist 000101309a00a000
>> Failed to find blacklist 0001013277c0a000
>> Failed to find blacklist 0001013277b0a000
>> Failed to find blacklist 0001013277a0a000
>> Failed to find blacklist 000101327790a000
>> Failed to find blacklist 000101303140a000
>> Failed to find blacklist 0001013a3280a000
>>
>> What do these mean?
> 
> Ah, I forgot that ia64 has function descriptor :(
> That means kprobes initial code has failed to get correct
> entry address of the blacklisted functions.
> 
> In include/linux/kprobes.h, I defined NOKPROBE_SYMBOL to store
> the addresses of blacklisted functions as below,
> 
> #define __NOKPROBE_SYMBOL(fname)                        \
> static unsigned long __used                             \
>         __attribute__((section("_kprobe_blacklist")))   \
>         _kbl_addr_##fname = (unsigned long)fname;
> #define NOKPROBE_SYMBOL(fname)  __NOKPROBE_SYMBOL(fname)
> 
> _kbl_addr_XX stores the address of the function, but on IA64,
> it stores the address of function descriptor.
> 
> Since those addresses are only used with kallsyms to lookup
> function size, I think I should use a macro to store correct
> function address instead of the address of function descriptor
> on ia64 (and similar arch).
> But I'm not sure which macro I should use... Is there any good way
> to get the address of function, instead of function descriptor?

Hmm, there is no general interface for retrieving the function entry
address from function pointer. I'd like to propose constant_function_entry()
macro for this purpose in linux/types.h (and arch-dep implementation will be
in asm/types.h)

BTW, as far as I can see, powerpc64 may have same problem. I'm not sure
about powerpc64 ABI, and recently it seems that they introduced ABIv2
support. The problem is, it seems that ppc64 ABIv2 has two function entries
and I don't know which entry should I use for kallsyms. Is that enough
to return (unsigned long)fname always on ABIv2 ?

At least on ppc64 ABIv1, I know I should return ((func_descr_t *)func)->entry ...

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


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