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: <1250645916.18426.12.camel@mulgrave.site>
Date:	Tue, 18 Aug 2009 19:38:36 -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 18:31 -0700, Roland McGrath wrote:
> > Actually, I think we do; the module loader is a runtime linker, after
> > all.  [...]
> 
> Indeed you do.  I've just read some of the parts of ld that normally
> address this issue for HPPA.  They don't run for ld -r.  So this is just
> another fine example of the lunacy of the ET_REL .ko madness that would be
> naturally avoided by a sensible tweaked ET_DYN scheme.

Using ET_DYN would have made our life easier when trying to code the
kernel module loader as well.  The basic problem is, of course, that
this is simple on an x86, so it didn't matter that much for the initial
implementation.  It just becomes less simple on anything else.

>   But that battle was
> lost way, way back in the long, long ago, so long ago they were probably
> even still making HPPA machines then.

Well, since they're still making parisc machines, I assume you mean
further back than when the production lines knocked off today?

> > 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.
> 
> Not with ld -r as it is today.  That's what ld does for you in proper final
> links.  It looks to me like you might be able to enable some special mode
> ("finalish link" for -r) with a hack to HPPA ld to apply this stub-creation
> logic based on the assumption that the symbols in the relocs will be
> resolved to themselves, and barf on you if they're used for SHN_UNDEF symbols.
> But nobody cares enough to fiddle with ld.

So that leaves us stuck with the current implementation and still
needing a solution for the duplicate section names?

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/