linux-kernel - Re: ARM: relocation out of range (when loading a module)

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: <20110112163854.GE11039@n2100.arm.linux.org.uk>
Date:	Wed, 12 Jan 2011 16:38:54 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Matthieu CASTET <matthieu.castet@...rot.com>
Cc:	Rabin Vincent <rabin@....in>,
	Alexander Holler <holler@...oftware.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	Nicolas Pitre <nico@...xnic.net>
Subject: Re: ARM: relocation out of range (when loading a module)

On Wed, Jan 12, 2011 at 05:25:28PM +0100, Matthieu CASTET wrote:
> Russell King - ARM Linux a écrit :
>> On Tue, Jan 11, 2011 at 09:16:38PM +0530, Rabin Vincent wrote:
>>> It's possible to hack around this by placing the initramfs at the end of
>>> the kernel image rather than at the beginning with the rest of the init
>>> data.  Something like the below should work, although you should also
>>> probably take care of alignment and also have this section freed when
>>> the rest of the init data is freed.
>>
>> You're then running into problems as _sdata.._edata is copied to RAM on
>> XIP kernels, and you really don't want to waste time copying the
>> initramfs to RAM.
>>
> But in this case initramfs is after edata and before bss.

Right, so that isn't a concern.

> So where is the problem ?

There is a problem with it, as noted by Rabin.  The initramfs will
never be freed.  Let's try to find a proper solution to this rather
than everyone sticking their half-baked ideas at it.  Let's see if
we can rearrange the _entire_ layout in a way that sorts this out
once and for all without making things even more complicated than
they already are today.

We've already got enough variables to think about here without having
yet more freeable sections scattered in the middle of the existing
layout.
--
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/