[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YhZYpnlCQpz3m5ds@hirez.programming.kicks-ass.net>
Date: Wed, 23 Feb 2022 16:54:14 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Josh Poimboeuf <jpoimboe@...hat.com>, x86@...nel.org,
joao@...rdrivepizza.com, hjl.tools@...il.com,
andrew.cooper3@...rix.com, linux-kernel@...r.kernel.org,
ndesaulniers@...gle.com, keescook@...omium.org,
samitolvanen@...gle.com, mark.rutland@....com,
alyssa.milburn@...el.com, Miroslav Benes <mbenes@...e.cz>,
Masami Hiramatsu <mhiramat@...nel.org>,
Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [PATCH 04/29] x86/livepatch: Validate __fentry__ location
On Wed, Feb 23, 2022 at 03:49:41PM +0100, Peter Zijlstra wrote:
> > Since we would want rec->ip if the pointer is before the ftrace
> > instruction. But we would need to audit all use cases and make sure this is
> > not called from any hot paths (in a callback).
> >
> > This will affect kprobes and BPF as they both use ftrace_location() as well.
>
> Yes, I already fixed kprobes, still trying to (re)discover how to run
> the bpf-selftests, that stuff is too painful :-(
Ok, I think I managed... I'm obviously hitting the WARN_ON_ONCE() in
is_ftrace_location(). Funnily, no dead kernel, so that's something I
suppose.
Now, I'm trying to make sense of that code, but all that !ftrace_managed
code scares me to death.
At the very least __bpf_arch_text_poke() needs a bunch of help. Let me
go prod it with something sharp to see what falls out ...
Powered by blists - more mailing lists