linux-kernel - Re: [PATCH] selftests/ftrace: update kprobe syntax error test for ppc64le

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: <20241105082018.GA29862@gate.crashing.org>
Date: Tue, 5 Nov 2024 02:20:18 -0600
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Hari Bathini <hbathini@...ux.ibm.com>
Cc: Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
        Steven Rostedt <rostedt@...dmis.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Madhavan Srinivasan <maddy@...ux.ibm.com>,
        "Naveen N. Rao" <naveen@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        linux-trace-kernel@...r.kernel.org,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] selftests/ftrace: update kprobe syntax error test for ppc64le

Hi!

On Mon, Nov 04, 2024 at 11:06:23PM +0530, Hari Bathini wrote:
> Seems like a bit of misunderstanding there. Function entry here intends
> to mean the actual start of function code (function prologue) - after
> GEP and function profiling sequence (mflr r0; bl mcount).

What you call "function entry" here simply does not exist.  The compiler
can -- and ***WILL***, ***DOES*** -- mix up all of that.  In particular,
"function prologue" does not exist at all (on any architecture worth
its salt, including PowerPC), and all instructions you consider part of
a function prologue might end up anywhere.  The "profiling sequence" is
part of that btw, and that typically ends up *not* the first thing in
the function, not the first thing after the LEP (register saves are
earlier often, they are generated in that order in the first place,
but they can (and will) be moved if that schedules better).

> Function arguments can be accessed with kprobe only while setting a
> probe at an address the kernel treats as function start address.

That is a silly assumption to make.  There is no guarantee you can
access function arguments *at all*, we're not in 1975 anymore.  You
*need* to look at debug information if you want to deal with anything
about your high-level language program.  Looking at the machine code
can only tell you about the machine state, whatever is in registers
etc.

> Note that the test case pass criteria here is setting probe to fail by
> providing an address (sym+offset) beyond the function start address.
> 
> And in this specific test case (with "vfs_read+8", where vfs_read is
> the symbol and '8' is the offset), the test case was failing on powerpc
> because setting the probe at 'sym+8' was succeeding, as anywhere between
> 'sym' to 'sym+16' is treated as function start address on powerpc:

Yeah, fragile tests sometimes break.  Changing a randomly chosen number
to some other randomly chosen number will not fix the problem (but you
can postpone having to deal with it, sure!)

Segher