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:	Thu, 10 Feb 2011 14:41:25 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	Sachin Verma <imschnvrm@...il.com>, Rabin Vincent <rabin@....in>,
	Alexander Holler <holler@...oftware.de>,
	Dave Martin <dave.martin@...aro.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	catalin.marinas@....com
Subject: Re: ARM: relocation out of range (when loading a module)

On Thu, 10 Feb 2011, Russell King - ARM Linux wrote:

> On Thu, Jan 27, 2011 at 12:43:54AM -0500, Nicolas Pitre wrote:
> > The MMU-less kernel should still favor allocations close to the kernel 
> > text for modules, and anything else away from the kernel going 
> > downwards.
> > 
> > Otherwise a veneer should be created by the module symbol resolver such 
> > that if the branch distance to reach, say, printk is too large, then the 
> > following code would have to be dynamically generated right next to the 
> > module:
> > 
> > 	ldr	pc, [pc, #-4]
> > 	.word	<far_away_symbol>
> > 
> > Then, in your module, you patch the branch relocation for printk so that 
> > it branches to the code above instead, and then store the address of 
> > printk at the location represented by the .word directive.
> 
> What you're suggesting is what we used to do with the old user-space
> module tools, which would've been nice to carry forwards to the new
> module code.  I never found a way to do it.
> 
> The problems:
> 1. Where do you create those veneers?
> 2. How many veneers do you allocate space for?
> 3. How do you determine that you need a veneer?
> 
> While you can say "next to the module" for (1), you can only do that at
> the point in time when the space for the module is allocated, and you
> need to know at that point how much space you require.

You would have to guess of course.  Having a guess of 1/2 the module 
size should be pretty safe.  So allocating 3/2 the space in 
module_alloc(), and then suffice to free the unused portion in 
module_finalize().

> For (2), you could always allocate space for one veneer per symbol present
> in the module, but that's very wasteful.
> 
> (3) is almost impossible to know ahead of time as you don't have the
> relocations, realistically you have to allocate one veneer per symbol,
> and as you don't know whether it's a data or code symbol, you'll have
> to allocate one veneer for every symbol in a module.

I don't think you may know the number of symbols in advance either 
anyway.

> I really don't like it, and I don't see that this is sanely solvable
> without giving architectures much more control over module loading,
> which I don't think will ever happen.  It's probably simpler to build
> modules with whatever that magic option is to tell GCC to always generate
> 'far call' veneers for everything rather than trying to 'fix' the kernel
> module loader.

Well, this is certainly possible indeed to just use -mlong-calls to 
build modules which would solve the issue right away, and with a smaller 
cost than if each function calls were going through a veneer, but with a 
higher cost than a relocatable direct branch.  So this could be decided 
with a Kconfig option.


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/