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: <alpine.LFD.2.00.1101111048010.16547@xanadu.home>
Date:	Tue, 11 Jan 2011 11:01:14 -0500 (EST)
From:	Nicolas Pitre <nico@...xnic.net>
To:	Alexander Holler <holler@...oftware.de>
Cc:	linux-kernel@...r.kernel.org, linux@....linux.org.uk
Subject: Re: ARM: relocation out of range (when loading a module)

On Tue, 11 Jan 2011, Alexander Holler wrote:

> Am 10.01.2011 23:26, schrieb Nicolas Pitre:
> > On Mon, 10 Jan 2011, Alexander Holler wrote:
> > 
> > > I've build a kernel 2.6.37 for an armv5-device which includes an initramfs
> > > of
> > > about 16MB (uncompressed, result is a kernel of about 6MB) and I now
> > > getting
> > > errors when trying to load a module (which is included in that initramfs):
> > 
> > Do you really need to have such a bit initramfs?
> 
> Not really, but it is handier to use than a separate file.
> 
> > What you can do to work around this issue is to load your initramfs
> > separately as a initrd ramdisk image. , and not combine it with the
> > kernel image.
> 
> Point is that I would like to understand why including an initramfs has such
> consequences.

The layout of the kernel virtual memory goes like this:

0xbf000000 to 0xbfffffff: kernel module area
0xc0008000 and above: kernel image

The module area is located just before the kernel memory because this 
allows function calls from modules to be linked directly without any 
indirect branches.  For that to work, the branch destination has to be 
within 32MB of its origin location.

Now the kernel image has its __init section located at the beginning. It 
is located there because of some alignment restriction, and the 
initramfs data is located in the __init section.  So if your initramfs 
is about 16MB, plus the size of the module area which is also 16MB you 
get a distance from a loaded module to the actual kernel core bigger 
than the possible branch fixup.


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