linux-kernel - Re: [PATCH 2/2] selftests/ftrace: Update multiple kprobes test for powerpc

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] [day] [month] [year] [list]

Date:   Thu, 29 Jun 2017 18:38:29 +0530
From:   "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 2/2] selftests/ftrace: Update multiple kprobes test for
 powerpc

On 2017/06/29 09:57AM, Masami Hiramatsu wrote:
> On Thu, 29 Jun 2017 00:13:24 +0530
> "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com> wrote:
> 
> > On 2017/06/28 11:16PM, Masami Hiramatsu wrote:
> > > > > diff --git 
> > > > > a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc 
> > > > > b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> > > > > new file mode 100644
> > > > > index 0000000..d259031
> > > > > --- /dev/null
> > > > > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> > > > > @@ -0,0 +1,28 @@
> > > > > +#!/bin/sh
> > > > > +# description: Kprobe event auto/manual naming
> > > > > +
> > > > > +disable_events
> > > > > +echo > kprobe_events
> > > > > +
> > > > > +:;: "Add an event on function without name" ;:
> > > > > +
> > > > > +FUNC=`grep -m 10 " [tT] [^.]*$" /proc/kallsyms | tail -n 1 | cut -f 3 -d " "`
> > > > 
> > > > On powerpc, this always ends up using a blacklisted function. So, I 
> > > > think we need a way to find a function that is not black listed.  
> > > 
> > > Hmm, if we increase the -m argument, like -m 100, is that still
> > > in a blacklisted function?
> > 
> > Yes, most of the initial symbols are exception vectors which are 
> > blacklisted.
> 
> Hmm, then how about this? :)
> 
> grep _stext -A 1000 | grep -m 10 " [tT] [^.]*$" /proc/kallsyms

That just happened to block the test ;)
I think your suggestion to use schedule/vfs_read is probably the best 
option. I will update your patch and post it.

> 
> > 
> > > 
> > > > However, one of the issues is that debugfs does not show all the address 
> > > > ranges that are blacklisted. I am coming up with a way to address that 
> > > > and will post patches once I have it working.
> > > 
> > > Would you find that is only on powerpc or generic issue?
> > 
> > I meant the address _ranges_ that are blacklisted such as the ones with 
> > __kprobes annotation and __entry_text and so on.
> 
> I see, but we can also check the address by comparing the address
> of symbols, which also can be retrieved from kallsyms.

Yes, but this is very platform specific and will result in a lot of 
checks, arm64 especially.

> Since the test case is also applied to stable kernel, I don't want
> to make it depending on some special kernel tweaks.

Sure, makes sense. For now, I think it's best to keep the test simple.  
But, we can enhance these later to consider the blacklist.

Thanks,
Naveen

> 
> > > 
> > > > 
> > > > With those patches, we should be able to select symbols that are not 
> > > > blacklisted.
> > > 
> > > Or, maybe we can use generic function, like "schedule" or "vfs_read"
> > > etc.
> > 
> > Yes, I think this will be good for the generic test, but may not help 
> > selecting a dot symbol on powerpc.
> 
> Right, and it depends on what gcc version and option is specified.
> So, maybe we can skip the test if there is no such symbols.
> 
> I intended to test the symbols with some dot-suffix, but it seems
> ppc64 has dot-started symbols, right? If there is no dot-suffixed
> symbols, I think this test should skip the test case.
> 
> Thank you,
> 
> 
> 
> -- 
> Masami Hiramatsu <mhiramat@...nel.org>
>