[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200828134825.GB71981@C02TD0UTHF1T.local>
Date: Fri, 28 Aug 2020 14:48:25 +0100
From: Mark Rutland <mark.rutland@....com>
To: peterz@...radead.org
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
linux-kernel@...r.kernel.org, Eddy_Wu@...ndmicro.com,
x86@...nel.org, davem@...emloft.net, rostedt@...dmis.org,
naveen.n.rao@...ux.ibm.com, anil.s.keshavamurthy@...el.com,
linux-arch@...r.kernel.org, cameron@...dycamel.com,
oleg@...hat.com, will@...nel.org, paulmck@...nel.org
Subject: Re: [PATCH v4 04/23] arm64: kprobes: Use generic kretprobe
trampoline handler
On Fri, Aug 28, 2020 at 03:37:18PM +0200, peterz@...radead.org 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@...nel.org>
> > > ---
> > > 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.
Hmm, I see (and this is not a new problem with this series, just
existing weirdness).
It looks like that's inconsistently an arch's stack pointer (e.g. x86,
arm64) or frame pointer (e.g. arm). IMO it'd be nicer if we could make
that the stack pointer consistently, but that's a separate cleanup, and
apparently not a big deal.
Thanks,
Mark.
Powered by blists - more mailing lists