linux-kernel - Re: [PATCH v2 2/2] selftests/ftrace: Add new test case which checks for optimized probes

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]

Message-Id: <1682506809.uus6y0ir3i.naveen@linux.ibm.com>
Date:   Wed, 26 Apr 2023 16:31:46 +0530
From:   "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Akanksha J N <akanksha@...ux.ibm.com>,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org, rostedt@...dmis.org,
        shuah@...nel.org
Subject: Re: [PATCH v2 2/2] selftests/ftrace: Add new test case which checks
 for optimized probes

Masami Hiramatsu wrote:
> On Tue, 25 Apr 2023 10:58:30 +0530
> "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com> wrote:
> 
>> Masami Hiramatsu wrote:
>> > On Tue, 18 Apr 2023 15:25:57 +0530
>> > Akanksha J N <akanksha@...ux.ibm.com> wrote:
>> > 
>> >> Add new test case kprobe_opt_types.tc which enables and checks
>> >> if each probe has been optimized in order to test potential issues with
>> >> optimized probes.
>> >> The '|| continue' is added with the echo statement to ignore errors that
>> >> are caused by trying to add kprobes to non probeable lines and continue
>> >> with the test.
>> >> Signed-off-by: Akanksha J N <akanksha@...ux.ibm.com>
>> >> ---
>> >>  .../ftrace/test.d/kprobe/kprobe_opt_types.tc  | 34 +++++++++++++++++++
>> >>  1 file changed, 34 insertions(+)
>> >>  create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_types.tc
>> >> 
>> >> diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_types.tc b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_types.tc
>> >> new file mode 100644
>> >> index 000000000000..54e4800b8a13
>> >> --- /dev/null
>> >> +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_opt_types.tc
>> >> @@ -0,0 +1,34 @@
>> >> +#!/bin/sh
>> >> +# SPDX-License-Identifier: GPL-2.0-or-later
>> >> +# Copyright (C) 2023 Akanksha J N, IBM corporation
>> >> +# description: Register/unregister optimized probe
>> >> +# requires: kprobe_events
>> >> +
>> >> +case `uname -m` in
>> >> +x86_64)
>> >> +;;
>> >> +arm*)
>> >> +;;
>> >> +ppc*)
>> >> +;;
>> >> +*)
>> >> +  echo "Please implement other architecture here"
>> >> +  exit_unsupported
>> >> +esac
>> >> +
>> >> +DEFAULT=$(cat /proc/sys/debug/kprobes-optimization)
>> >> +echo 1 > /proc/sys/debug/kprobes-optimization
>> >> +for i in `seq 0 255`; do
>> >> +        echo  "p:testprobe $FUNCTION_FORK+${i}" > kprobe_events || continue
>> >> +        echo 1 > events/kprobes/enable || continue
>> >> +        (echo "forked")
>> >> +        PROBE_TYPE=$(cat /sys/kernel/debug/kprobes/list | grep $FUNCTION_FORK | awk '{print $4}' | awk '{print substr($0,2,length($0)-2)}')
>> > 
>> > I think we can make it simply;
>> > 
>> > PROBE=$(grep $FUNCTION_FORK /sys/kernel/debug/kprobes/list)
>> > 
>> >> +        echo 0 > events/kprobes/enable
>> >> +        echo > kprobe_events
>> >> +        if [ $PROBE_TYPE = "OPTIMIZED" ]; then
>> > 
>> > and
>> > 
>> > if echo $PROBE | grep -q OPTIMIZED; then
>> > 
>> >> +                echo "$DEFAULT" >  /proc/sys/debug/kprobes-optimization
>> >> +                exit_pass
>> >> +        fi
>> >> +done
>> >> +echo "$DEFAULT" >  /proc/sys/debug/kprobes-optimization
>> >> +echo "Done"
>> > 
>> > Hmm, this test does NOT return any error. It always returns success.
>> 
>> Good catch!
>> 
>> > I understand that optimization may not be possible within 256 bytes
>> > from the beginning of the function.
>> 
>> Is that true in practice? Looking at x86 and ppc64le, it looks like we 
>> will almost always be able to optimize at least one of the instructions 
>> within the first 256 bytes of kernel_clone(). That's one of the primary 
>> purposes of this test.
> 
> Yeah, usually it should not happen. But since we don't disassemble it,
> we can not ensure that. So this depends on the compiler at last.

Ok.

> 
>> 
>> Are there valid reasons why we may not be able to optimize instructions?
> 
> For example, if the compiler starts inserting some checker instruction
> on each instruction boundary for security, it may prevent optimizing
> kprobes. Usually it should not happen (because it bloat up the kernel size)
> but we cannot deny the possibility of such new feature as an option
> in the future.
> 
>> 
>> > In that case, you can return
>> > "unresolved", and not echoing "Done" but the reason why it is
>> > unresolved.
> 
> Even in that case, it can notify such case as "unresolved", then we
> can notice it. (something like WARN_ON)

Sure, exiting as "Unresolved" should help point out a potential issue 
with optimizing probes, rather than labeling this as a failure.


Thanks,
Naveen