Messages in this thread | | | Date | Sat, 26 Feb 2022 16:09:46 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH v2 15/39] x86/ibt,kprobes: Fix more +0 assumptions |
| |
On Fri, 25 Feb 2022 09:14:09 -0500 Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 25 Feb 2022 11:46:23 +0100 > Peter Zijlstra <peterz@infradead.org> wrote: > > > Given all that, kprobe users are in a bit of a bind. Determining the > > __fentry__ point basically means they *have* to first read the function > > assembly to figure out where it is. > > Technically I think that's what kprobes has been designed for. But > realistically, I do not think anyone actually does that (outside of > academic and niche uses).
Yeah, raw kprobe user must check the instruction boundary anyway. And if possible, I would like to keep the kprobe (in kprobe level) as it is.
> Really, when people use func+0 they just want to trace the function, and > ftrace is the fastest way to do so, and if it's not *exactly* at function > entry, but includes the arguments, then it should be fine.
Yes, that is another (sub) reason why I introduced fprobe. ;-)
OK, I understand that we should not allow to probe on endbr unless user really wants it. Let me add a KPROBE_FLAG_RAW_ENTRY for that special purpose. If the flag is not set (by default), the kprobe::addr will be shifted automatically. ANyway, this address translation must be done in check_ftrace_location instead of kprobe_lookup_name(). Let me make another patch. Also, selftest and document must be updated with that.
> That said, perhaps we should add a config to know if the architecture > uses function entry or the old mcount that is after the frame set up (that > is, you can not get to the arguments). > > CONFIG_HAVE_FTRACE_FUNCTION_START ?
Hmm, ENDBR is not always there, and except x86, most of the arch will make it 'n'. (x86 is a special case.)
> > Because, if the arch still uses the old mcount method (where it's after the > frame set up), then a kprobe at func+0 really wants the breakpoint. > > -- Steve >
Thank you,
-- Masami Hiramatsu <mhiramat@kernel.org>
| |