linux-kernel - Re: ARM + jprobes/kretprobes SEGV/hangs/OOPS in 2.6.29 kernel

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: <alpine.LFD.2.00.0909011347470.6044@xanadu.home>
Date:	Tue, 01 Sep 2009 13:56:17 -0400 (EDT)
From:	Nicolas Pitre <nico@....org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Russell King <rmk+lkml@....linux.org.uk>,
	venki kaps <venkiece2005@...il.com>,
	"sagar.abhishek@...il.com" <sagar.abhishek@...il.com>,
	"jkenisto@...ibm.com" <jkenisto@...ibm.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"prasanna@...ibm.com" <prasanna@...ibm.com>
Subject: Re: ARM + jprobes/kretprobes SEGV/hangs/OOPS in 2.6.29 kernel

On Tue, 1 Sep 2009, Catalin Marinas wrote:

> On Tue, 2009-09-01 at 15:25 +0100, Russell King wrote:
> > On Tue, Sep 01, 2009 at 02:54:54PM +0100, Catalin Marinas wrote:
> > > venki kaps <venkiece2005@...il.com> wrote:
> > > > I have found the exact problem with respect to ARM jprobes.
> > > >
> > > > The problem with configure i.e, CONFIG_ARM_UNWIND = y; is enabled.
> > > 
> > > I haven't followed the kprobes implementation for ARM but does it make
> > > any assumptions about the existence of a frame pointer on the stack?
> > > Enabling stack unwinding automatically disables the framepointer.
> > 
> > If it uses CALLER_ADDRESSx() then it won't work with unwinding enabled.
> > See 5613/1 (which is pending in the devel branch.)
> 
> In addition to that, when CONFIG_FRAME_POINTER is disabled, the lr
> register isn't always saved on the stack by the called function. I'm not
> sure whether kretprobe_trampoline is aware of this.

The way a kretprobe works is to put a trap at the very first instruction 
of the targetted function, preserve the value of LR when the trap is 
hit, and substitute it with the address of kretprobe_trampoline.  Then 
the original first instruction is emulated to pass over the trap point 
and normal execution is resumed.  So whether or not LR is then saved on 
the stack doesn't matter to kretprobe_trampoline as it will restore the 
LR value saved during the initial trap.

Of course if you end up generating a backtrace within a kretprobed 
function then the result might look funny.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/