linux-kernel - Re: [RFC PATCH 03/14] arm: kprobes: Use generic kretprobe trampoline handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20200827000405.60aa815dbb6f1417dc9da867@kernel.org>
Date:   Thu, 27 Aug 2020 00:04:05 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     peterz@...radead.org
Cc:     Eddy Wu <Eddy_Wu@...ndmicro.com>, linux-kernel@...r.kernel.org,
        x86@...nel.org, "David S . Miller" <davem@...emloft.net>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        "Naveen N . Rao" <naveen.n.rao@...ux.ibm.com>,
        Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
        linux-arch@...r.kernel.org
Subject: Re: [RFC PATCH 03/14] arm: kprobes: Use generic kretprobe
 trampoline handler

On Wed, 26 Aug 2020 16:10:25 +0200
peterz@...radead.org wrote:

> On Wed, Aug 26, 2020 at 04:08:52PM +0200, peterz@...radead.org wrote:
> > On Wed, Aug 26, 2020 at 10:46:43PM +0900, Masami Hiramatsu wrote:
> > >  static __used __kprobes void *trampoline_handler(struct pt_regs *regs)
> > >  {
> > > +	return (void *)kretprobe_trampoline_handler(regs,
> > > +				(unsigned long)&kretprobe_trampoline,
> > > +				regs->ARM_fp);
> > >  }
> > 
> > Does it make sense to have the generic code have a weak
> > trampoline_handler() implemented like the above? It looks like a number
> > of architectures have this trivial variant and it seems pointless to
> > duplicate this.
> 
> Argh, I replied to the wrong variant, I mean the one that uses
> kernel_stack_pointer(regs).

Would you mean using kernel_stack_pointer() for the frame_pointer?
Some arch will be OK, but others can not get the framepointer by that.
(that is because the stack layout is different on the function prologue
and returned address, e.g. x86...)

> 
> Then the architecture only needs to implement kernel_stack_pointer() if
> there is nothing else to do.

There are 2 patterns of kretprobe trampoline handling, one is using
a kprobe which hooks the trampoline code. In this case, the
trampoline handler is a kprobe pre_handler. And another is not
using kprobe, but trampoline code saves (a part of)pt_regs and call
the trampoline handler. In this case the trampoline handler will get
the (maybe incomplete) pt_regs. Actually, arm kretprobe handler doesn't
save the sp register for some reason...

Thank you,
-- 
Masami Hiramatsu <mhiramat@...nel.org>