linux-kernel - Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64

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: <1403141433.4768.1.camel@concordia>
Date:	Thu, 19 Jun 2014 11:30:33 +1000
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	"Suzuki K. Poulose" <suzuki@...ibm.com>,
	Tony Luck <tony.luck@...il.com>,
	Paul Mackerras <paulus@...ba.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	linux-ia64@...r.kernel.org, sparse@...isli.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-tip-commits@...r.kernel.org, anil.s.keshavamurthy@...el.com,
	Ingo Molnar <mingo@...nel.org>,
	Fenghua Yu <fenghua.yu@...el.com>,
	Arnd Bergmann <arnd@...db.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Chris Wright <chrisw@...s-sol.org>,
	yrl.pp-manager.tt@...achi.com, akataria@...are.com,
	Tony Luck <tony.luck@...el.com>,
	Kevin Hao <haokexin@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	rdunlap@...radead.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	dl9pf@....de, Andrew Morton <akpm@...ux-foundation.org>,
	linuxppc-dev@...ts.ozlabs.org,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find
 blacklist" error on ia64 and ppc64

On Wed, 2014-06-18 at 17:46 +0900, Masami Hiramatsu wrote:
> (2014/06/18 16:56), Michael Ellerman wrote:
> > On Fri, 2014-06-06 at 15:38 +0900, Masami Hiramatsu wrote:
> >> Ping?
> >>
> >> I guess this should go to 3.16 branch, shouldn't it?
> > 
> >>> diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
> >>> index bfb6ded..8b89d65 100644
> >>> --- a/arch/powerpc/include/asm/types.h
> >>> +++ b/arch/powerpc/include/asm/types.h
> >>> @@ -25,6 +25,17 @@ typedef struct {
> >>>  	unsigned long env;
> >>>  } func_descr_t;
> >>>  
> >>> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> >>> +/*
> >>> + * On PPC64 ABIv1 the function pointer actually points to the
> >>> + * function's descriptor. The first entry in the descriptor is the
> >>> + * address of the function text.
> >>> + */
> >>> +#define function_entry(fn)	(((func_descr_t *)(fn))->entry)
> >>> +#else
> >>> +#define function_entry(fn)	((unsigned long)(fn))
> >>> +#endif
> > 
> > We already have ppc_function_entry(), can't you use that?
> 
> I'd like to ask you whether the address which ppc_function_entry() returns on
> PPC ABIv2 is really same address in kallsyms or not.
> As you can see, kprobes uses function_entry() to get the actual entry address
> where kallsyms knows. I have not much information about that, but it seems that
> the "global entry point" is the address which kallsyms knows, isn't it?

OK. I'm not sure off the top of my head which address kallsyms knows about, but
yes it's likely that it is the global entry point.

I recently sent a patch to add ppc_global_function_entry(), because we need it
in the ftrace code. Once that is merged you could use that.

How do you hit the original problem, you don't actually specify in your commit
message? Something with kprobes obviously, but what exactly? I'll try and
reproduce it here.

cheers


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