linux-kernel - Re: [RFC][PATCH 1/2 v2] ftrace/x86: Allow for arguments to be passed in to REGS by default

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: <20201028112916.50bcbc69@oasis.local.home>
Date:   Wed, 28 Oct 2020 11:29:16 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     linux-kernel@...r.kernel.org
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jiri Kosina <jikos@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [RFC][PATCH 1/2 v2] ftrace/x86: Allow for arguments to be
 passed in to REGS by default

Hi Masami,

Talking with Peter and Thomas on IRC, where they really don't like
passing a partial pt_regs around, got me thinking of redoing the REGS
parameter of ftrace. Kprobes is the only user that requires the full
registers being saved, and that's only because some kprobe user might
want them.

On Wed, 28 Oct 2020 10:25:02 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
>
>  typedef void (*ftrace_func_t)(unsigned long ip, unsigned long parent_ip,
>  			      struct ftrace_ops *op, struct pt_regs *regs);
>  

Most registers of pt_regs at a start of a function is rather useless.
What if we got rid of FL_SAVE_REGS all together and had a "ftrace_regs"
structure passed in that would have only access to all the argument
registers, the stack pointer and the instruction pointer?

Then kprobes could just create its own pt_regs, fill in all the data
from ftrace_regs and then fill the rest with zeros or possibly whatever
the values currently are (does it really matter what those registers
are?), including flags.

Not only would this simplify the code, it would probably allow moving
more of the kprobe code from the arch specific to the generic code, and
remove a lot of duplication.

This would also help speed up the processing of live kernel patching.

And best of all, it would give everything access to the arguments of a
function and a stack pointer with out (ab)using pt_regs.

Do you think this would be feasible?

-- Steve