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]
Date:	Sun, 21 Jul 2013 22:37:53 +0100
From:	Will Deacon <will.deacon@....com>
To:	Jed Davis <jld@...illa.com>
Cc:	Russell King <linux@....linux.org.uk>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Robert Richter <rric@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"oprofile-list@...ts.sf.net" <oprofile-list@...ts.sf.net>
Subject: Re: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y

Hello Jed,

Thanks for the reply.

On Sat, Jul 20, 2013 at 05:46:55AM +0100, Jed Davis wrote:
> On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> > On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> [...]
> > > Effects of this are probably limited to failure of EHABI unwinding when
> > > starting from a function that uses r7 to restore its stack pointer, but
> > > the possibility for further breakage (which would be invisible on
> > > non-Thumb kernels) is worrying.
> [...]
> > I'm struggling to understand exactly the problem that this patch is trying
> > to address. If it's just a code consistency issue, I don't think it's worth
> > it (I actually find it less confusing the way we currently have things) but
> > if there is a real bug, perhaps you could provide a testcase?
> 
> There is a real bug here, but my commit message wasn't very clear.  This
> was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
> (with my other recently posted patch applied), because kernel/sched.c is
> built with -fno-omit-frame-pointer (which is wrong, but that's a problem
> for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
> and somewhere along the line the unwinder gets the r11 value instead.
> This would also apply to any function with a variable-length array, but
> __schedule happens to have the perf hook I was trying to use.

Ok, I think I'm with you now. I also think that a better solution would be
to try and limit the r7/fp confusion to one place, perhaps behind something
like:

void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);

then that function can act as the bridge between pt_regs (where we leave
everything as it is) and stackframe (where we assign either r7 or fp into
the fp member). Then we just fix up the call sites to pass the regs they're
interested in to our new function.

What do you think?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ