[PATCH v13 bpf-next 0/1] fprobe: Introduce fprobe function entry/exit probe

[PATCH v13 bpf-next 0/1] fprobe: Introduce fprobe function entry/exit probe

[Masami Hiramatsu]

Hi,

Here is the 13th version of rethook x86 port. This is developed for a part
of fprobe series [1] for hooking function return. But since I forgot to send
it to arch maintainers, that caused conflict with IBT and SLS mitigation series.
Now I picked the x86 rethook part and send it to x86 maintainers to be
reviewed.

[1] https://lore.kernel.org/all/164735281449.1084943.12438881786173547153.stgit@devnote2/T/#u

Note that this patch is still for the bpf-next since the rethook itself
is on the bpf-next tree. But since this also uses the ANNOTATE_NOENDBR
macro which has been introduced by IBT/ENDBR patch, to build this series
you need to merge the tip/master branch with the bpf-next.
(hopefully, it is rebased soon)

The fprobe itself is for providing the function entry/exit probe
with multiple probe point. The rethook is a sub-feature to hook the
function return as same as kretprobe does. Eventually, I would like
to replace the kretprobe's trampoline with this rethook.

Thank you,

---

Masami Hiramatsu (1):
      rethook: x86: Add rethook x86 implementation


 arch/x86/Kconfig                 |    1 
 arch/x86/include/asm/unwind.h    |    8 ++-
 arch/x86/kernel/Makefile         |    1 
 arch/x86/kernel/kprobes/common.h |    1 
 arch/x86/kernel/rethook.c        |  121 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 131 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/kernel/rethook.c

--
Masami Hiramatsu (Linaro) <mhiramat@kernel.org>

[PATCH v13 bpf-next 1/1] rethook: x86: Add rethook x86 implementation

[Masami Hiramatsu]

Add rethook for x86 implementation. Most of the code has been copied from
kretprobes on x86.

Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
 Changes in v13:
  - Add no ENDBR annotation for return trampoline code.
  - Replace ret with ASM_RET for Straight-Line-Speculation mitigation.
 Changes in v11:
  - Mark arch_rethook_fixup_return() as NOKPROBE_SYMBOL.
  - Add a function prototype of arch_rethook_trampoline_callback
    to suppress warning.
 Changes in v10:
  - Add a dummy @mcount to arch_rethook_prepare().
 Changes in v5:
  - Fix a build error if !CONFIG_KRETPROBES and !CONFIG_RETHOOK.
 Changes in v4:
  - fix stack backtrace as same as kretprobe does.
---
 arch/x86/Kconfig                 |    1 
 arch/x86/include/asm/unwind.h    |    8 ++-
 arch/x86/kernel/Makefile         |    1 
 arch/x86/kernel/kprobes/common.h |    1 
 arch/x86/kernel/rethook.c        |  121 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 131 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/kernel/rethook.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9b356da6f46b..1270b65a5546 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -221,6 +221,7 @@ config X86
 	select HAVE_KPROBES_ON_FTRACE
 	select HAVE_FUNCTION_ERROR_INJECTION
 	select HAVE_KRETPROBES
+	select HAVE_RETHOOK
 	select HAVE_KVM
 	select HAVE_LIVEPATCH			if X86_64
 	select HAVE_MIXED_BREAKPOINTS_REGS
diff --git a/arch/x86/include/asm/unwind.h b/arch/x86/include/asm/unwind.h
index 2a1f8734416d..192df5b2094d 100644
--- a/arch/x86/include/asm/unwind.h
+++ b/arch/x86/include/asm/unwind.h
@@ -5,6 +5,7 @@
 #include <linux/sched.h>
 #include <linux/ftrace.h>
 #include <linux/kprobes.h>
+#include <linux/rethook.h>
 #include <asm/ptrace.h>
 #include <asm/stacktrace.h>
 
@@ -16,7 +17,7 @@ struct unwind_state {
 	unsigned long stack_mask;
 	struct task_struct *task;
 	int graph_idx;
-#ifdef CONFIG_KRETPROBES
+#if defined(CONFIG_KRETPROBES) || defined(CONFIG_RETHOOK)
 	struct llist_node *kr_cur;
 #endif
 	bool error;
@@ -107,6 +108,11 @@ static inline
 unsigned long unwind_recover_kretprobe(struct unwind_state *state,
 				       unsigned long addr, unsigned long *addr_p)
 {
+#ifdef CONFIG_RETHOOK
+	if (is_rethook_trampoline(addr))
+		return rethook_find_ret_addr(state->task, (unsigned long)addr_p,
+					     &state->kr_cur);
+#endif
 #ifdef CONFIG_KRETPROBES
 	return is_kretprobe_trampoline(addr) ?
 		kretprobe_find_ret_addr(state->task, addr_p, &state->kr_cur) :
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 6aef9ee28a39..792a893a5cc5 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
 obj-$(CONFIG_FTRACE_SYSCALLS)	+= ftrace.o
 obj-$(CONFIG_X86_TSC)		+= trace_clock.o
 obj-$(CONFIG_TRACING)		+= trace.o
+obj-$(CONFIG_RETHOOK)		+= rethook.o
 obj-$(CONFIG_CRASH_CORE)	+= crash_core_$(BITS).o
 obj-$(CONFIG_KEXEC_CORE)	+= machine_kexec_$(BITS).o
 obj-$(CONFIG_KEXEC_CORE)	+= relocate_kernel_$(BITS).o crash.o
diff --git a/arch/x86/kernel/kprobes/common.h b/arch/x86/kernel/kprobes/common.h
index 7d3a2e2daf01..c993521d4933 100644
--- a/arch/x86/kernel/kprobes/common.h
+++ b/arch/x86/kernel/kprobes/common.h
@@ -6,6 +6,7 @@
 
 #include <asm/asm.h>
 #include <asm/frame.h>
+#include <asm/insn.h>
 
 #ifdef CONFIG_X86_64
 
diff --git a/arch/x86/kernel/rethook.c b/arch/x86/kernel/rethook.c
new file mode 100644
index 000000000000..3e916361c33b
--- /dev/null
+++ b/arch/x86/kernel/rethook.c
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * x86 implementation of rethook. Mostly copied from arch/x86/kernel/kprobes/core.c.
+ */
+#include <linux/bug.h>
+#include <linux/rethook.h>
+#include <linux/kprobes.h>
+#include <linux/objtool.h>
+
+#include "kprobes/common.h"
+
+__visible void arch_rethook_trampoline_callback(struct pt_regs *regs);
+
+/*
+ * When a target function returns, this code saves registers and calls
+ * arch_rethook_trampoline_callback(), which calls the rethook handler.
+ */
+asm(
+	".text\n"
+	".global arch_rethook_trampoline\n"
+	".type arch_rethook_trampoline, @function\n"
+	"arch_rethook_trampoline:\n"
+#ifdef CONFIG_X86_64
+	ANNOTATE_NOENDBR	/* This is only jumped from ret instruction */
+	/* Push a fake return address to tell the unwinder it's a kretprobe. */
+	"	pushq $arch_rethook_trampoline\n"
+	UNWIND_HINT_FUNC
+	/* Save the 'sp - 8', this will be fixed later. */
+	"	pushq %rsp\n"
+	"	pushfq\n"
+	SAVE_REGS_STRING
+	"	movq %rsp, %rdi\n"
+	"	call arch_rethook_trampoline_callback\n"
+	RESTORE_REGS_STRING
+	/* In the callback function, 'regs->flags' is copied to 'regs->sp'. */
+	"	addq $8, %rsp\n"
+	"	popfq\n"
+#else
+	/* Push a fake return address to tell the unwinder it's a kretprobe. */
+	"	pushl $arch_rethook_trampoline\n"
+	UNWIND_HINT_FUNC
+	/* Save the 'sp - 4', this will be fixed later. */
+	"	pushl %esp\n"
+	"	pushfl\n"
+	SAVE_REGS_STRING
+	"	movl %esp, %eax\n"
+	"	call arch_rethook_trampoline_callback\n"
+	RESTORE_REGS_STRING
+	/* In the callback function, 'regs->flags' is copied to 'regs->sp'. */
+	"	addl $4, %esp\n"
+	"	popfl\n"
+#endif
+	ASM_RET
+	".size arch_rethook_trampoline, .-arch_rethook_trampoline\n"
+);
+NOKPROBE_SYMBOL(arch_rethook_trampoline);
+
+/*
+ * Called from arch_rethook_trampoline
+ */
+__used __visible void arch_rethook_trampoline_callback(struct pt_regs *regs)
+{
+	unsigned long *frame_pointer;
+
+	/* fixup registers */
+	regs->cs = __KERNEL_CS;
+#ifdef CONFIG_X86_32
+	regs->gs = 0;
+#endif
+	regs->ip = (unsigned long)&arch_rethook_trampoline;
+	regs->orig_ax = ~0UL;
+	regs->sp += sizeof(long);
+	frame_pointer = &regs->sp + 1;
+
+	/*
+	 * The return address at 'frame_pointer' is recovered by the
+	 * arch_rethook_fixup_return() which called from this
+	 * rethook_trampoline_handler().
+	 */
+	rethook_trampoline_handler(regs, (unsigned long)frame_pointer);
+
+	/*
+	 * Copy FLAGS to 'pt_regs::sp' so that arch_rethook_trapmoline()
+	 * can do RET right after POPF.
+	 */
+	regs->sp = regs->flags;
+}
+NOKPROBE_SYMBOL(arch_rethook_trampoline_callback);
+
+/*
+ * arch_rethook_trampoline() skips updating frame pointer. The frame pointer
+ * saved in arch_rethook_trampoline_callback() points to the real caller
+ * function's frame pointer. Thus the arch_rethook_trampoline() doesn't have
+ * a standard stack frame with CONFIG_FRAME_POINTER=y.
+ * Let's mark it non-standard function. Anyway, FP unwinder can correctly
+ * unwind without the hint.
+ */
+STACK_FRAME_NON_STANDARD_FP(arch_rethook_trampoline);
+
+/* This is called from rethook_trampoline_handler(). */
+void arch_rethook_fixup_return(struct pt_regs *regs,
+			       unsigned long correct_ret_addr)
+{
+	unsigned long *frame_pointer = &regs->sp + 1;
+
+	/* Replace fake return address with real one. */
+	*frame_pointer = correct_ret_addr;
+}
+NOKPROBE_SYMBOL(arch_rethook_fixup_return);
+
+void arch_rethook_prepare(struct rethook_node *rh, struct pt_regs *regs, bool mcount)
+{
+	unsigned long *stack = (unsigned long *)regs->sp;
+
+	rh->ret_addr = stack[0];
+	rh->frame = regs->sp;
+
+	/* Replace the return addr with trampoline addr */
+	stack[0] = (unsigned long) arch_rethook_trampoline;
+}
+NOKPROBE_SYMBOL(arch_rethook_prepare);

Re: [PATCH v13 bpf-next 1/1] rethook: x86: Add rethook x86 implementation

[Peter Zijlstra]

On Wed, Mar 23, 2022 at 11:34:59AM +0900, Masami Hiramatsu wrote:
> Add rethook for x86 implementation. Most of the code has been copied from
> kretprobes on x86.

Right; as said, I'm really unhappy with growing a carbon copy of this
stuff instead of sharing. Can we *please* keep it a single instance?
Them being basically indentical, it should be trivial to have
CONFIG_KPROBE_ON_RETHOOK (or somesuch) and just share this.

Also, what's rethook for anyway?

> diff --git a/arch/x86/kernel/kprobes/common.h b/arch/x86/kernel/kprobes/common.h
> index 7d3a2e2daf01..c993521d4933 100644
> --- a/arch/x86/kernel/kprobes/common.h
> +++ b/arch/x86/kernel/kprobes/common.h
> @@ -6,6 +6,7 @@
>  
>  #include <asm/asm.h>
>  #include <asm/frame.h>
> +#include <asm/insn.h>
>  
>  #ifdef CONFIG_X86_64
>  
> diff --git a/arch/x86/kernel/rethook.c b/arch/x86/kernel/rethook.c
> new file mode 100644
> index 000000000000..3e916361c33b
> --- /dev/null
> +++ b/arch/x86/kernel/rethook.c
> @@ -0,0 +1,121 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * x86 implementation of rethook. Mostly copied from arch/x86/kernel/kprobes/core.c.
> + */
> +#include <linux/bug.h>
> +#include <linux/rethook.h>
> +#include <linux/kprobes.h>
> +#include <linux/objtool.h>
> +
> +#include "kprobes/common.h"
> +
> +__visible void arch_rethook_trampoline_callback(struct pt_regs *regs);
> +
> +/*
> + * When a target function returns, this code saves registers and calls
> + * arch_rethook_trampoline_callback(), which calls the rethook handler.
> + */
> +asm(
> +	".text\n"
> +	".global arch_rethook_trampoline\n"
> +	".type arch_rethook_trampoline, @function\n"
> +	"arch_rethook_trampoline:\n"
> +#ifdef CONFIG_X86_64
> +	ANNOTATE_NOENDBR	/* This is only jumped from ret instruction */
> +	/* Push a fake return address to tell the unwinder it's a kretprobe. */
> +	"	pushq $arch_rethook_trampoline\n"
> +	UNWIND_HINT_FUNC
	"	pushq $" __stringify(__KERNEL_DS) "\n" /* %ss */
	/* Save the 'sp - 16', this will be fixed later. */
> +	"	pushq %rsp\n"
> +	"	pushfq\n"
> +	SAVE_REGS_STRING
> +	"	movq %rsp, %rdi\n"
> +	"	call arch_rethook_trampoline_callback\n"
> +	RESTORE_REGS_STRING
	/* In the callback function, 'regs->flags' is copied to 'regs->ss'. */

	this comment could do with a 'why' though... Because neither
	this nor the one in the handler really explains why it is
	important to have popf last

	"	addq $16, %rsp\n"
> +	"	popfq\n"
> +#else

same for i386:

> +	/* Push a fake return address to tell the unwinder it's a kretprobe. */
> +	"	pushl $arch_rethook_trampoline\n"
> +	UNWIND_HINT_FUNC
	/* Save the 'sp - 8', this will be fixed later. */
	"	pushl %ss\n"
> +	"	pushl %esp\n"
> +	"	pushfl\n"
> +	SAVE_REGS_STRING
> +	"	movl %esp, %eax\n"
> +	"	call arch_rethook_trampoline_callback\n"
> +	RESTORE_REGS_STRING
	/* In the callback function, 'regs->flags' is copied to 'regs->ss'. */
	"	addl $8, %esp\n"
> +	"	popfl\n"
> +#endif
> +	ASM_RET
> +	".size arch_rethook_trampoline, .-arch_rethook_trampoline\n"
> +);
> +NOKPROBE_SYMBOL(arch_rethook_trampoline);
> +
> +/*
> + * Called from arch_rethook_trampoline
> + */
> +__used __visible void arch_rethook_trampoline_callback(struct pt_regs *regs)
> +{
> +	unsigned long *frame_pointer;
> +
> +	/* fixup registers */
> +	regs->cs = __KERNEL_CS;
> +#ifdef CONFIG_X86_32
> +	regs->gs = 0;
> +#endif
> +	regs->ip = (unsigned long)&arch_rethook_trampoline;
> +	regs->orig_ax = ~0UL;
	regs->sp += 2*sizeof(long);
> +	frame_pointer = &regs->sp + 1;
> +
> +	/*
> +	 * The return address at 'frame_pointer' is recovered by the
> +	 * arch_rethook_fixup_return() which called from this
> +	 * rethook_trampoline_handler().
> +	 */
> +	rethook_trampoline_handler(regs, (unsigned long)frame_pointer);
> +
> +	/*
> +	 * Copy FLAGS to 'pt_regs::sp' so that arch_rethook_trapmoline()
> +	 * can do RET right after POPF.
> +	 */
	regs->ss = regs->flags;
> +}
> +NOKPROBE_SYMBOL(arch_rethook_trampoline_callback);

Re: [PATCH v13 bpf-next 1/1] rethook: x86: Add rethook x86 implementation

[Masami Hiramatsu]

On Wed, 23 Mar 2022 09:05:26 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, Mar 23, 2022 at 11:34:59AM +0900, Masami Hiramatsu wrote:
> > Add rethook for x86 implementation. Most of the code has been copied from
> > kretprobes on x86.
> 
> Right; as said, I'm really unhappy with growing a carbon copy of this
> stuff instead of sharing. Can we *please* keep it a single instance?

OK, then let me update the kprobe side too.

> Them being basically indentical, it should be trivial to have
> CONFIG_KPROBE_ON_RETHOOK (or somesuch) and just share this.

Yes, ideally it should use CONFIG_HAVE_RETHOOK since the rethook arch port
must be a copy of the kretprobe implementation. But for safety, I think
having CONFIG_KPROBE_ON_RETHOOK is a good idea until replacing all kretprobe
implementations.

> 
> Also, what's rethook for anyway?

Rethook is a feature which hooks the function return. Most of the
logic came from the kretprobe. Simply to say, 'kretprobe - kprobe' is 
the rethook :)

Thank you,

> 
> > diff --git a/arch/x86/kernel/kprobes/common.h b/arch/x86/kernel/kprobes/common.h
> > index 7d3a2e2daf01..c993521d4933 100644
> > --- a/arch/x86/kernel/kprobes/common.h
> > +++ b/arch/x86/kernel/kprobes/common.h
> > @@ -6,6 +6,7 @@
> >  
> >  #include <asm/asm.h>
> >  #include <asm/frame.h>
> > +#include <asm/insn.h>
> >  
> >  #ifdef CONFIG_X86_64
> >  
> > diff --git a/arch/x86/kernel/rethook.c b/arch/x86/kernel/rethook.c
> > new file mode 100644
> > index 000000000000..3e916361c33b
> > --- /dev/null
> > +++ b/arch/x86/kernel/rethook.c
> > @@ -0,0 +1,121 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * x86 implementation of rethook. Mostly copied from arch/x86/kernel/kprobes/core.c.
> > + */
> > +#include <linux/bug.h>
> > +#include <linux/rethook.h>
> > +#include <linux/kprobes.h>
> > +#include <linux/objtool.h>
> > +
> > +#include "kprobes/common.h"
> > +
> > +__visible void arch_rethook_trampoline_callback(struct pt_regs *regs);
> > +
> > +/*
> > + * When a target function returns, this code saves registers and calls
> > + * arch_rethook_trampoline_callback(), which calls the rethook handler.
> > + */
> > +asm(
> > +	".text\n"
> > +	".global arch_rethook_trampoline\n"
> > +	".type arch_rethook_trampoline, @function\n"
> > +	"arch_rethook_trampoline:\n"
> > +#ifdef CONFIG_X86_64
> > +	ANNOTATE_NOENDBR	/* This is only jumped from ret instruction */
> > +	/* Push a fake return address to tell the unwinder it's a kretprobe. */
> > +	"	pushq $arch_rethook_trampoline\n"
> > +	UNWIND_HINT_FUNC
> 	"	pushq $" __stringify(__KERNEL_DS) "\n" /* %ss */
> 	/* Save the 'sp - 16', this will be fixed later. */
> > +	"	pushq %rsp\n"
> > +	"	pushfq\n"
> > +	SAVE_REGS_STRING
> > +	"	movq %rsp, %rdi\n"
> > +	"	call arch_rethook_trampoline_callback\n"
> > +	RESTORE_REGS_STRING
> 	/* In the callback function, 'regs->flags' is copied to 'regs->ss'. */
> 
> 	this comment could do with a 'why' though... Because neither
> 	this nor the one in the handler really explains why it is
> 	important to have popf last
> 
> 	"	addq $16, %rsp\n"
> > +	"	popfq\n"
> > +#else
> 
> same for i386:
> 
> > +	/* Push a fake return address to tell the unwinder it's a kretprobe. */
> > +	"	pushl $arch_rethook_trampoline\n"
> > +	UNWIND_HINT_FUNC
> 	/* Save the 'sp - 8', this will be fixed later. */
> 	"	pushl %ss\n"
> > +	"	pushl %esp\n"
> > +	"	pushfl\n"
> > +	SAVE_REGS_STRING
> > +	"	movl %esp, %eax\n"
> > +	"	call arch_rethook_trampoline_callback\n"
> > +	RESTORE_REGS_STRING
> 	/* In the callback function, 'regs->flags' is copied to 'regs->ss'. */
> 	"	addl $8, %esp\n"
> > +	"	popfl\n"
> > +#endif
> > +	ASM_RET
> > +	".size arch_rethook_trampoline, .-arch_rethook_trampoline\n"
> > +);
> > +NOKPROBE_SYMBOL(arch_rethook_trampoline);
> > +
> > +/*
> > + * Called from arch_rethook_trampoline
> > + */
> > +__used __visible void arch_rethook_trampoline_callback(struct pt_regs *regs)
> > +{
> > +	unsigned long *frame_pointer;
> > +
> > +	/* fixup registers */
> > +	regs->cs = __KERNEL_CS;
> > +#ifdef CONFIG_X86_32
> > +	regs->gs = 0;
> > +#endif
> > +	regs->ip = (unsigned long)&arch_rethook_trampoline;
> > +	regs->orig_ax = ~0UL;
> 	regs->sp += 2*sizeof(long);
> > +	frame_pointer = &regs->sp + 1;
> > +
> > +	/*
> > +	 * The return address at 'frame_pointer' is recovered by the
> > +	 * arch_rethook_fixup_return() which called from this
> > +	 * rethook_trampoline_handler().
> > +	 */
> > +	rethook_trampoline_handler(regs, (unsigned long)frame_pointer);
> > +
> > +	/*
> > +	 * Copy FLAGS to 'pt_regs::sp' so that arch_rethook_trapmoline()
> > +	 * can do RET right after POPF.
> > +	 */
> 	regs->ss = regs->flags;
> > +}
> > +NOKPROBE_SYMBOL(arch_rethook_trampoline_callback);


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v13 bpf-next 1/1] rethook: x86: Add rethook x86 implementation

[Peter Zijlstra]

On Wed, Mar 23, 2022 at 08:41:19PM +0900, Masami Hiramatsu wrote:

> > Also, what's rethook for anyway?
> 
> Rethook is a feature which hooks the function return. Most of the
> logic came from the kretprobe. Simply to say, 'kretprobe - kprobe' is 
> the rethook :)

I got that far, but why did you take the bother to do these patches? Why
wasn't 'use kretprobe' a good enough option?

Re: [PATCH v13 bpf-next 1/1] rethook: x86: Add rethook x86 implementation

[Masami Hiramatsu]

On Wed, 23 Mar 2022 13:34:54 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, Mar 23, 2022 at 08:41:19PM +0900, Masami Hiramatsu wrote:
> 
> > > Also, what's rethook for anyway?
> > 
> > Rethook is a feature which hooks the function return. Most of the
> > logic came from the kretprobe. Simply to say, 'kretprobe - kprobe' is 
> > the rethook :)
> 
> I got that far, but why did you take the bother to do these patches? Why
> wasn't 'use kretprobe' a good enough option?

Ah, sorry about lacking the background story.

Actually this came from Jiri's request of multiple kprobe for bpf[1].
He tried to solve an issue that starting bpf with multiple kprobe will
take a long time because bpf-kprobe will wait for RCU grace period for
sync rcu events.

Jiri wanted to attach a single bpf handler to multiple kprobes and
he tried to introduce multiple-probe interface to kprobe. So I asked
him to use ftrace and kretprobe-like hook if it is only for the
function entry and exit, instead of adding ad-hoc interface
to kprobes. So I introduced fprobe (kprobe like interface for ftrace)
and rethook (this is a generic return hook feature for fprobe exit handler)[2].

[1] https://lore.kernel.org/all/20220104080943.113249-1-jolsa@kernel.org/T/#u
[2] https://lore.kernel.org/all/164191321766.806991.7930388561276940676.stgit@devnote2/T/#u

This is the reason why I need to split the kretprobe's trampoline as
rethook. Kretprobe is only for probing a single function entry/exit,
thus it does not suit for this purpose.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v13 bpf-next 1/1] rethook: x86: Add rethook x86 implementation

[Alexei Starovoitov]

On Wed, Mar 23, 2022 at 4:41 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> On Wed, 23 Mar 2022 09:05:26 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Wed, Mar 23, 2022 at 11:34:59AM +0900, Masami Hiramatsu wrote:
> > > Add rethook for x86 implementation. Most of the code has been copied from
> > > kretprobes on x86.
> >
> > Right; as said, I'm really unhappy with growing a carbon copy of this
> > stuff instead of sharing. Can we *please* keep it a single instance?
>
> OK, then let me update the kprobe side too.
>
> > Them being basically indentical, it should be trivial to have
> > CONFIG_KPROBE_ON_RETHOOK (or somesuch) and just share this.
>
> Yes, ideally it should use CONFIG_HAVE_RETHOOK since the rethook arch port
> must be a copy of the kretprobe implementation. But for safety, I think
> having CONFIG_KPROBE_ON_RETHOOK is a good idea until replacing all kretprobe
> implementations.

Masami,

you're respinning this patch to combine
arch_rethook_trampoline and __kretprobe_trampoline
right?

Re: [PATCH v13 bpf-next 1/1] rethook: x86: Add rethook x86 implementation

[Masami Hiramatsu]

On Thu, 24 Mar 2022 19:03:43 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> On Wed, Mar 23, 2022 at 4:41 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > On Wed, 23 Mar 2022 09:05:26 +0100
> > Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > > On Wed, Mar 23, 2022 at 11:34:59AM +0900, Masami Hiramatsu wrote:
> > > > Add rethook for x86 implementation. Most of the code has been copied from
> > > > kretprobes on x86.
> > >
> > > Right; as said, I'm really unhappy with growing a carbon copy of this
> > > stuff instead of sharing. Can we *please* keep it a single instance?
> >
> > OK, then let me update the kprobe side too.
> >
> > > Them being basically indentical, it should be trivial to have
> > > CONFIG_KPROBE_ON_RETHOOK (or somesuch) and just share this.
> >
> > Yes, ideally it should use CONFIG_HAVE_RETHOOK since the rethook arch port
> > must be a copy of the kretprobe implementation. But for safety, I think
> > having CONFIG_KPROBE_ON_RETHOOK is a good idea until replacing all kretprobe
> > implementations.
> 
> Masami,
> 
> you're respinning this patch to combine
> arch_rethook_trampoline and __kretprobe_trampoline
> right?

Yes, let me send the first patch set (for x86 at first).

BTW, can you review these 2 patches? These are only for the fprobes,
so it can be picked to bpf-next.

https://lore.kernel.org/all/164802091567.1732982.1242854551611267542.stgit@devnote2/T/#u

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v13 bpf-next 1/1] rethook: x86: Add rethook x86 implementation

[Alexei Starovoitov]

On Thu, Mar 24, 2022 at 7:21 PM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> On Thu, 24 Mar 2022 19:03:43 -0700
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > On Wed, Mar 23, 2022 at 4:41 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > >
> > > On Wed, 23 Mar 2022 09:05:26 +0100
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > > On Wed, Mar 23, 2022 at 11:34:59AM +0900, Masami Hiramatsu wrote:
> > > > > Add rethook for x86 implementation. Most of the code has been copied from
> > > > > kretprobes on x86.
> > > >
> > > > Right; as said, I'm really unhappy with growing a carbon copy of this
> > > > stuff instead of sharing. Can we *please* keep it a single instance?
> > >
> > > OK, then let me update the kprobe side too.
> > >
> > > > Them being basically indentical, it should be trivial to have
> > > > CONFIG_KPROBE_ON_RETHOOK (or somesuch) and just share this.
> > >
> > > Yes, ideally it should use CONFIG_HAVE_RETHOOK since the rethook arch port
> > > must be a copy of the kretprobe implementation. But for safety, I think
> > > having CONFIG_KPROBE_ON_RETHOOK is a good idea until replacing all kretprobe
> > > implementations.
> >
> > Masami,
> >
> > you're respinning this patch to combine
> > arch_rethook_trampoline and __kretprobe_trampoline
> > right?
>
> Yes, let me send the first patch set (for x86 at first).

great

> BTW, can you review these 2 patches? These are only for the fprobes,
> so it can be picked to bpf-next.
>
> https://lore.kernel.org/all/164802091567.1732982.1242854551611267542.stgit@devnote2/T/#u

Yes. They look good. Will push them soon.

Re: [PATCH v13 bpf-next 0/1] fprobe: Introduce fprobe function entry/exit probe

[Masami Hiramatsu]

Hi,

The title is not updated. It should be;

rethook: x86: Add rethook x86 porting (drived from "fprobe: Introduce fprobe function entry/exit probe" series)

Thank you,

On Wed, 23 Mar 2022 11:34:46 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> Hi,
> 
> Here is the 13th version of rethook x86 port. This is developed for a part
> of fprobe series [1] for hooking function return. But since I forgot to send
> it to arch maintainers, that caused conflict with IBT and SLS mitigation series.
> Now I picked the x86 rethook part and send it to x86 maintainers to be
> reviewed.
> 
> [1] https://lore.kernel.org/all/164735281449.1084943.12438881786173547153.stgit@devnote2/T/#u
> 
> Note that this patch is still for the bpf-next since the rethook itself
> is on the bpf-next tree. But since this also uses the ANNOTATE_NOENDBR
> macro which has been introduced by IBT/ENDBR patch, to build this series
> you need to merge the tip/master branch with the bpf-next.
> (hopefully, it is rebased soon)
> 
> The fprobe itself is for providing the function entry/exit probe
> with multiple probe point. The rethook is a sub-feature to hook the
> function return as same as kretprobe does. Eventually, I would like
> to replace the kretprobe's trampoline with this rethook.
> 
> Thank you,
> 
> ---
> 
> Masami Hiramatsu (1):
>       rethook: x86: Add rethook x86 implementation
> 
> 
>  arch/x86/Kconfig                 |    1 
>  arch/x86/include/asm/unwind.h    |    8 ++-
>  arch/x86/kernel/Makefile         |    1 
>  arch/x86/kernel/kprobes/common.h |    1 
>  arch/x86/kernel/rethook.c        |  121 ++++++++++++++++++++++++++++++++++++++
>  5 files changed, 131 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/kernel/rethook.c
> 
> --
> Masami Hiramatsu (Linaro) <mhiramat@kernel.org>


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v13 bpf-next 0/1] fprobe: Introduce fprobe function entry/exit probe

[Mark Rutland]

On Wed, Mar 23, 2022 at 11:34:46AM +0900, Masami Hiramatsu wrote:
> Hi,

Hi Masami,

> Here is the 13th version of rethook x86 port. This is developed for a part
> of fprobe series [1] for hooking function return. But since I forgot to send
> it to arch maintainers, that caused conflict with IBT and SLS mitigation series.
> Now I picked the x86 rethook part and send it to x86 maintainers to be
> reviewed.
> 
> [1] https://lore.kernel.org/all/164735281449.1084943.12438881786173547153.stgit@devnote2/T/#u

As mentioned elsewhere, I have similar (though not identical) concerns
to Peter for the arm64 patch, which was equally unreviewed by
maintainers, and the overall structure.

> Note that this patch is still for the bpf-next since the rethook itself
> is on the bpf-next tree. But since this also uses the ANNOTATE_NOENDBR
> macro which has been introduced by IBT/ENDBR patch, to build this series
> you need to merge the tip/master branch with the bpf-next.
> (hopefully, it is rebased soon)

I thought we were going to drop the series from the bpf-next tree so
that this could all go through review it had missed thusfar.

Is that still the plan? What's going on?

> The fprobe itself is for providing the function entry/exit probe
> with multiple probe point. The rethook is a sub-feature to hook the
> function return as same as kretprobe does. Eventually, I would like
> to replace the kretprobe's trampoline with this rethook.

Can we please start by converting each architecture to rethook?

Ideally we'd unify things such that each architecture only needs *one*
return trampoline that both ftrace and krpboes can use, which'd be
significantly easier to get right and manage.

Thanks,
Mark.

Re: [PATCH v13 bpf-next 0/1] fprobe: Introduce fprobe function entry/exit probe

[Masami Hiramatsu]

On Wed, 23 Mar 2022 14:18:40 +0000
Mark Rutland <mark.rutland@arm.com> wrote:

> On Wed, Mar 23, 2022 at 11:34:46AM +0900, Masami Hiramatsu wrote:
> > Hi,
> 
> Hi Masami,
> 
> > Here is the 13th version of rethook x86 port. This is developed for a part
> > of fprobe series [1] for hooking function return. But since I forgot to send
> > it to arch maintainers, that caused conflict with IBT and SLS mitigation series.
> > Now I picked the x86 rethook part and send it to x86 maintainers to be
> > reviewed.
> > 
> > [1] https://lore.kernel.org/all/164735281449.1084943.12438881786173547153.stgit@devnote2/T/#u
> 
> As mentioned elsewhere, I have similar (though not identical) concerns
> to Peter for the arm64 patch, which was equally unreviewed by
> maintainers, and the overall structure.

Yes, those should be reviewed by arch maintainers.

> 
> > Note that this patch is still for the bpf-next since the rethook itself
> > is on the bpf-next tree. But since this also uses the ANNOTATE_NOENDBR
> > macro which has been introduced by IBT/ENDBR patch, to build this series
> > you need to merge the tip/master branch with the bpf-next.
> > (hopefully, it is rebased soon)
> 
> I thought we were going to drop the series from the bpf-next tree so
> that this could all go through review it had missed thusfar.
> 
> Is that still the plan? What's going on?

Now the arm64 (and other arch) port is reverted from bpf-next.
I'll send those to you soon.
Since bpf-next is focusing on x86 at first, I chose this for review in
this version. Sorry for confusion.

> 
> > The fprobe itself is for providing the function entry/exit probe
> > with multiple probe point. The rethook is a sub-feature to hook the
> > function return as same as kretprobe does. Eventually, I would like
> > to replace the kretprobe's trampoline with this rethook.
> 
> Can we please start by converting each architecture to rethook?

Yes. As Peter pointed, I'm planning to add a kretprobe patches to use
rethook if available in that series. let me prepare it.

> 
> Ideally we'd unify things such that each architecture only needs *one*
> return trampoline that both ftrace and krpboes can use, which'd be
> significantly easier to get right and manage.

Agreed :-)

Thank you,

> 
> Thanks,
> Mark.


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH v13 bpf-next 0/1] fprobe: Introduce fprobe function entry/exit probe

[Mark Rutland]

On Wed, Mar 23, 2022 at 11:55:39PM +0900, Masami Hiramatsu wrote:
> On Wed, 23 Mar 2022 14:18:40 +0000
> Mark Rutland <mark.rutland@arm.com> wrote:
> 
> > On Wed, Mar 23, 2022 at 11:34:46AM +0900, Masami Hiramatsu wrote:
> > > Hi,
> > 
> > Hi Masami,
> > 
> > > Here is the 13th version of rethook x86 port. This is developed for a part
> > > of fprobe series [1] for hooking function return. But since I forgot to send
> > > it to arch maintainers, that caused conflict with IBT and SLS mitigation series.
> > > Now I picked the x86 rethook part and send it to x86 maintainers to be
> > > reviewed.
> > > 
> > > [1] https://lore.kernel.org/all/164735281449.1084943.12438881786173547153.stgit@devnote2/T/#u
> > 
> > As mentioned elsewhere, I have similar (though not identical) concerns
> > to Peter for the arm64 patch, which was equally unreviewed by
> > maintainers, and the overall structure.
> 
> Yes, those should be reviewed by arch maintainers.
> 
> > > Note that this patch is still for the bpf-next since the rethook itself
> > > is on the bpf-next tree. But since this also uses the ANNOTATE_NOENDBR
> > > macro which has been introduced by IBT/ENDBR patch, to build this series
> > > you need to merge the tip/master branch with the bpf-next.
> > > (hopefully, it is rebased soon)
> > 
> > I thought we were going to drop the series from the bpf-next tree so
> > that this could all go through review it had missed thusfar.
> > 
> > Is that still the plan? What's going on?
> 
> Now the arm64 (and other arch) port is reverted from bpf-next.
> I'll send those to you soon.

Ah; thanks for confirming!

> Since bpf-next is focusing on x86 at first, I chose this for review in
> this version. Sorry for confusion.

No problem; I think the confusion is all my own, so nothing to apologise
for! :)

> > > The fprobe itself is for providing the function entry/exit probe
> > > with multiple probe point. The rethook is a sub-feature to hook the
> > > function return as same as kretprobe does. Eventually, I would like
> > > to replace the kretprobe's trampoline with this rethook.
> > 
> > Can we please start by converting each architecture to rethook?
> 
> Yes. As Peter pointed, I'm planning to add a kretprobe patches to use
> rethook if available in that series. let me prepare it.
> 
> > Ideally we'd unify things such that each architecture only needs *one*
> > return trampoline that both ftrace and krpboes can use, which'd be
> > significantly easier to get right and manage.
> 
> Agreed :-)

Great!

Thanks,
Mark.