linux-kernel - Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu

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:	Fri, 15 Feb 2013 11:13:06 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	arm@...nel.org, Shawn Guo <shawn.guo@...aro.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Dinh Nguyen <dinguyen@...era.com>,
	Pavel Machek <pavel@...x.de>,
	Stephen Warren <swarren@...dia.com>,
	Simon Horman <horms+renesas@...ge.net.au>
Subject: Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link
	error

On Fri, Feb 15, 2013 at 11:05:14AM +0000, Arnd Bergmann wrote:
> $ size  obj-tmp/vmlinux -A
> obj-tmp/vmlinux  :
> section                  size         addr
> .head.text                504   3221258240
> .text                32707336   3221258752
> .text.head                  8   3253966088

Interesting... I wonder if that should be .head.text, or maybe just .text.
Looking at iMX, it's just the secondary startup, which is calling into
.head.text, so it would be much safer given the size of the .text segment
for it to be in .head.text.

> The .text section alone is just short of 32MB.

I suspect when it does go over that, we'll see a lot more link time
failures due to the 'bl' instructions failing to encode their PC relative
jumps.  The only solution then will be to switch everything to use the
less efficient long jumps (load address from literal pool, bx) which'll
also need much of the asm changed.  That also brings up the question
whether we want to penalize the kernel performance just to make
allyesconfig work... I guess we can make it a compile time option, which
of course allyesconfig will automatically enable.  I suspect we'll see
a lot of people mistakenly enabling it too though.
--
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/