On Fri, 28 Aug 2020 15:37:18 +0200
peterz@xxxxxxxxxxxxx wrote:
> On Fri, Aug 28, 2020 at 02:31:31PM +0100, Mark Rutland wrote:
> > Hi,
> >
> > On Fri, Aug 28, 2020 at 09:27:22PM +0900, Masami Hiramatsu wrote:
> > > Use the generic kretprobe trampoline handler, and use the
> > > kernel_stack_pointer(regs) for framepointer verification.
> > >
> > > Signed-off-by: Masami Hiramatsu <mhiramat@xxxxxxxxxx>
> > > ---
> > > arch/arm64/kernel/probes/kprobes.c | 78 +-----------------------------------
> > > 1 file changed, 3 insertions(+), 75 deletions(-)
> >
> > > + return (void *)kretprobe_trampoline_handler(regs, &kretprobe_trampoline,
> > > + (void *)kernel_stack_pointer(regs));
> > > }
> > >
> > > void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
> > > struct pt_regs *regs)
> > > {
> > > ri->ret_addr = (kprobe_opcode_t *)regs->regs[30];
> > > + ri->fp = (void *)kernel_stack_pointer(regs);
> >
> > This is probably a nomenclature problem, but what exactly is
> > kretprobe_instance::fp used for?
> >
> > I ask because arm64's frame pointer lives in x29 (and is not necessarily
> > the same as the stack pointer at function boundaries), so the naming
> > is potentially misleading and possibly worth a comment or rename.
>
> IIUC ri->rp is used for matching up the frame between the moment we
> install the return trampoline on the stack and actually hitting that
> trampoline.
Yeah, it is confusing, sorry. On x86, CONFIG_FRAME_POINTER can be disabled,
so we used the address of stack entry where arch_prepare_kretprobe() stores
the trampoline address.
For arm64 which doesn't use a stack entry for call, I decided to use the
stack address when the target function is called.
Indeed, it should be commented.
Thank you,
--
Masami Hiramatsu <mhiramat@xxxxxxxxxx>
