On Fri, 28 Aug 2020 15:37:18 +0200 [email protected] 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 <[email protected]> > > > --- > > > 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 <[email protected]>
