linux-kernel - Re: [PATCH 03/10] ftrace: Add register_ftrace

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]

Date:   Thu, 14 Nov 2019 13:48:27 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        X86 ML <x86@...nel.org>, Nadav Amit <nadav.amit@...il.com>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Song Liu <songliubraving@...com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH 03/10] ftrace: Add register_ftrace_direct()

On Thu, 14 Nov 2019 10:34:09 -0800
Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:

> > Alexei,
> >
> > Do you still need such a feature?
> >
> > Note, I just pushed my tree to my for-next tree, and also have a
> > ftrace/direct branch that ends with this patch set that is the basis of
> > the rest of the work of my code. Feel free to build against that
> > branch if you need to have something built on the net tree.  
> 
> I'm still trying to figure out what you meant
> by your suggestion to implement a modify_ftrace_direct().
> I was thinking something much simpler like
> modify_ftrace_direct(ip, old_call, new_ca);
> will just text poke that call addr from old to new if old matches

The main reason, is that then we need to add another arch specific
change, where as, the solution I suggested doesn't need anything new.
The less arch specific code we need the better.

> and will adjust ftrace inner bookkeeping.
> I don't understand why you want to malloc/free ftrace_ops for that.

We wouldn't need to allocate it, the stub could be something as simple
as:

struct ftrace_ops dummy_ops = {
	.func = ftrace_stub;
}

And just register that, where we set the hash to it, which would
require an malloc and free, but is that really a problem? A modify
shouldn't be a hot path, as text poke itself is going to be slow.

-- Steve