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: <20170216082851.c98f4a3375b25071e686962d@kernel.org>
Date:   Thu, 16 Feb 2017 08:28:51 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
Cc:     Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
        Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
        Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH] kretprobes: reject registration if a symbol offset is
 specified

On Wed, 15 Feb 2017 23:23:46 +0530
"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com> wrote:

> Hi Masami,
> 
> On 2017/02/14 07:32PM, Masami Hiramatsu wrote:
> > On Tue, 14 Feb 2017 14:01:18 +0530
> > "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com> wrote:
> > 
> > > Users shouldn't be able to specify an offset with kretprobes, as we always
> > > want to probe at function entry. Otherwise, we won't be able to capture
> > > the proper return address resulting in the kretprobe never firing.
> > > 
> > 
> > Nack, this should be checked by using kallsyms, since the
> > many non-exported kernel functions have same name.
> > Actually perf-probe is trying to put any probes(including return
> > probe) by using relative address from text-start symbol (_stext
> > or _text). In this case, kretprobe also can be set by _text+OFFSET.
> 
> Interesting. In my tests, 'perf probe' always chose the function name 
> for return probes on both x86 and powerpc. So, looking into it further, 
> I found commit 25dd9171f51c ("perf probe: Fix probing kretprobes") which 
> changed perf probe behavior due to how kprobe_events behaved. And 
> kprobe_events has always dis-allowed use of offset with kprobe_events.

Oops, it was so. That should be fixed correctly...

> 
> But, I agree -- we should allow use of offset with kretprobes.  
> Otherwise, we won't be able to probe functions that have the same name.

Yeah.

> 
> > 
> > So please rewrite this by using kallsyms_lookup_size_offset()
> > which tells you the address is actually on the beginning of
> > function or not.
> 
> Sure. This makes use of offsets and/or absolute addresses with 
> kretprobes safe. Patches on the way...

Thanks!

> 
> Thanks!
> - Naveen
> 
> > 
> > Thank you,
> > 
> > > With samples/kprobes/kretprobe_example.c including an offset:
> > > 	my_kretprobe.kp.offset = 40;
> > > 
> > > Before this patch, the probe gets planted but never fires.
> > > 
> > > After this patch:
> > > 	$ sudo insmod samples/kprobes/kretprobe_example.ko
> > > 	[sudo] password for naveen: 
> > > 	insmod: ERROR: could not insert module samples/kprobes/kretprobe_example.ko: Operation not permitted
> > > 
> > > And dmesg:
> > > 	[48253.757629] register_kretprobe failed, returned -22
> > > 
> > > Signed-off-by: Naveen N. Rao <naveen.n.rao@...ux.vnet.ibm.com>
> > > ---
> > >  kernel/kprobes.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > > index 60a702a05684..83ad7e440417 100644
> > > --- a/kernel/kprobes.c
> > > +++ b/kernel/kprobes.c
> > > @@ -1847,6 +1847,9 @@ int register_kretprobe(struct kretprobe *rp)
> > >  	int i;
> > >  	void *addr;
> > >  
> > > +	if (rp->kp.offset)
> > > +		return -EINVAL;
> > > +
> > >  	if (kretprobe_blacklist_size) {
> > >  		addr = kprobe_addr(&rp->kp);
> > >  		if (IS_ERR(addr))
> > > -- 
> > > 2.11.0
> > > 
> > 
> > 
> > -- 
> > Masami Hiramatsu <mhiramat@...nel.org>
> > 
> 


-- 
Masami Hiramatsu <mhiramat@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ