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]

Date:	Wed, 12 Jan 2011 16:23:08 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Dave Martin <dave.martin@...aro.org>
Cc:	Alexander Holler <holler@...oftware.de>,
	Rabin Vincent <rabin@....in>, 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 10:05:19AM -0600, Dave Martin wrote:
> In general, do we expect always to be able to avoid the situation
> where branches in the kernel may need to cover too large a range ...
> and is there any strategy for working aroung it?

It's not that big a problem - 99.999999% of setups never run into the
problem.  It's only those who use large initramfs's built into their
kernel image at present, and that is ultimately solvable.

I don't think we need to litter code with TODO comments.

> If we have problems branching from the modules area into vmlinux, we
> could possibly build modules with -fPIC : this would remove the
> restriction on branch range, though there would also be some
> performance impact for the modules...

That also brings in issues with GOT tables and the like, and also requires
different build options for modules and the main kernel.  I don't think
kbuild is setup to do that - and I'd argue that it's unnecessary if we
fix the layout of the kernel image.

As I said a few emails ago, shuffling sections around in the image is
not as trivial as it looks on the face of it as we make assumptions
about what is in _stext.._etext, _sdata.._edata, whether there's anything
between _etext.._sdata, and other symbolic ranges.

At the moment, _stext.._etext + _sdata.._edata covers the entire kernel
image - with the init sections at the start of _stext.  Putting the init
sections between _etext and _sdata makes a hole in the middle of that,
which may be suboptimal for page allocation.  It also means that the
range no longer covers all kernel stuff.  Also whether _stext = _text,
_sdata = _data, etc.

Another technicality is that some of these ranges are used for stuff like
DMA API debugging:

        if (overlap(addr, len, _text, _etext) ||
            overlap(addr, len, __start_rodata, __end_rodata))
                err_printk(dev, NULL, "DMA-API: device driver maps memory from kernel text or rodata [addr=%p] [len=%lu]\n", addr, len);

The last pieces of the puzzle is whether we have anything that implicitly
relies on the init section being low down and freeing its pages (eg, as
a way of stopping that memory being used for non-DMA stuff.)

I do have a patch which shuffles some of this stuff around, but I'm not
entirely happy with it yet.

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