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]

Date:	Tue, 25 Aug 2009 17:29:32 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	Roland McGrath <roland@...hat.com>, 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 Wed, 19 Aug 2009 11:08:36 am James Bottomley wrote:
> 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.

Actually, x86 was one of the archs which fucked us.  Richard Henderson and
I *had* this, but ld -shared without -fPIC helpfully tells you "you're doing
it wrong" on x86-64.

There were other issues, ISTR MIPS was a showstopper.  Google finds the
following summary I wrote when this stuff was fresher:

http://lkml.org/lkml/2003/1/12/271 :

	While ET_DYN modules are a reasonably serious win for ia64 (and
	probably hppa) (ie. -300 lines or so), they're a minor win for alpha
	and ppc64 (-100 lines or so), and no real change for arm, i386, ppc,
	sparc, and sparc64.  It's a lose for x86_64 (toolchain fixes, unless
	they want to use -fPIC for modules), mips and mips64 (major toolchain
	fixes, unless they want to use -fPIC for modules and stop using r28
	for current inside modules).

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

This isn't quite true; userspace should handle ET_DYN fine (at least, it
was supposed to).

So you could change any arch to use that, but it's a fair refactor if we leave
some archs behind.

If anyone's really interested, I can dig out the bits I have...

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

If this is not a "don't do that" bug, we could try hacking around it in
parisc's module_arch_frob_sections?

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