linux-kernel - Re: kernel segv with 2.6.31-rc6 ?

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: <1250643261.18426.8.camel@mulgrave.site>
Date:	Tue, 18 Aug 2009 18:54:21 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Roland McGrath <roland@...hat.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Helge Deller <deller@....de>,
	linux-parisc <linux-parisc@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: kernel segv with 2.6.31-rc6 ?

On Tue, 2009-08-18 at 17:14 -0700, Roland McGrath wrote:
> > Actually, for parisc, its not reasonable.  It's expected that our modules
> > have multiple text sections (we have to use -ffunction-sections to
> > generate them in order that the PCREL17 jump stubs can be interleaved).
> 
> I don't think you need what you think you need.  Having lots of sections in
> your .o's when you compile is fine.  These should be combined by the linker
> script that creates the .ko, however.  Unless I am missing something, there
> is no purpose to this section distinction at insmod time--it's only
> important for the relative layout of the parts of the .ko's text, which
> winds up contiguous whether laid out that way at ld -r (.ko creation) time
> or at insmod time.

Actually, I think we do; the module loader is a runtime linker, after
all.  We have specific module bugs we fixed by inserting relocation
stubs between the text sections.

Our specific problem is that the standard pa relocation is PCREL17 ...
as you can appreciate, 17 bits of relative jump isn't a lot.  If the
target isn't within the 17 bits, we have to insert a relocation stub to
do an indirect absolute jump thought the GOT.  Our problems occur when a
text section is wider than the 17 bits, which happens a lot in the
larger modules ... with nowhere to put the stub within range of the
relocation we can't load them.  Our fix is to split the text sections
with -ffunction-sections so we can be pretty much assured of having a
stub location within the 17 bits.

We don't care what they're called or anything.  We just care that
the .text is split up into multiple separately relocateable sections so
we can get the stubs within range of the jumps.

Now, of course, if the final linker could be persuaded to sprinkle
needed stubs through the text section and all we have to do is GOT
relocations, we don't need all the jiggery-pokery ... but I'm told this
can't be done.

James

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