linux-kernel - Re: [PATCH] arm: Add unwinding annotations for 64bit division functions

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1316689606.2053.29.camel@linaro1>
Date:	Thu, 22 Sep 2011 12:06:46 +0100
From:	"Jon Medhurst (Tixy)" <jon.medhurst@...aro.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Dave Martin <dave.martin@...aro.org>,
	Laura Abbott <lauraa@...eaurora.org>,
	Nicolas Pitre <nico@...xnic.net>, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] arm: Add unwinding annotations for 64bit division
 functions

On Thu, 2011-09-22 at 10:48 +0100, Catalin Marinas wrote:
> On 22 September 2011 08:28, Jon Medhurst (Tixy) <jon.medhurst@...aro.org> wrote:
> > On Wed, 2011-09-21 at 12:55 +0100, Russell King - ARM Linux wrote:
> >> Instructions such as VFP, kprobes tracing, etc are expected fault
> >> locations, and those are fairly well controlled where they can be placed.
> >> With things like ftrace, it certainly is the case that the unwinder can
> >> theoretically be called from almost anywhere in a function.
> >
> > Actually, kprobes can be places on any instruction in the kernel that
> > isn't in the section .kprobes.text.
> >
> > I also strongly suspect that stack unwinding won't happen correctly
> > across the boundary between the kprobes handling code and the function
> > which was probed - there's an awful lot of stack jiggery pokery going on
> > there.
> 
> Are people most likely to place kprobes on the first instruction of a
> function? 

I believe that is the usual case.

> We could improve things a bit in the unwinder and assume
> that if the fault address is the same as the .fnstart address, the
> return value is always in LR and the SP not affected (that's unwinding
> bytecode 0xb0). For a few instructions into the function prologue we
> can't reliably get the unwinding information.

That would help make it possible to unwind out of kprobes handlers to
the probed function. The kprobes code itself would need work as well,
and possibly the undef handler. Do we think it is worthwhile to do
this? 

-- 
Tixy

--
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/