linux-kernel - Re: revert PIE randomization?

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: <Pine.LNX.4.64.0703211940370.24602@blonde.wat.veritas.com>
Date:	Wed, 21 Mar 2007 20:01:50 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Kees Cook <kees@...flux.net>
cc:	Andrew Morton <akpm@...l.org>, Linus Torvalds <torvalds@...l.org>,
	Marcus Meissner <meissner@...e.de>, Andi Kleen <ak@...e.de>,
	Ingo Molnar <mingo@...e.hu>,
	Dave Jones <davej@...emonkey.org.uk>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	linux-kernel@...r.kernel.org
Subject: Re: revert PIE randomization?

On Wed, 21 Mar 2007, Kees Cook wrote:
> Hugh Dickins said:
> > Inconsistency detected by ld.so: rtld.c: 1217: dl_main:
> >  Assertion `_rtld_local._dl_rtld_map.l_libname' failed!
> 
> I'm trying to reproduce the problem you saw (so that I can then test 
> your proposed fix).  However, I haven't had any luck.  I've got a 
> pie-compiled version of bash, and I've been running it in a loop for a 
> while now with the original randomization patch.  (I can clearly see the 
> base address bouncing around.)
> 
> I'm at just over 10 million exec's, and I haven't hit the problem.  :(
> 
> Do you have any clues on how to trigger this more reliably?

It was in doing kernel builds that I hit it, nothing special: an
overnight cycle of kernel building would collapse in a few hours.
openSUSE 10.2.

If that doesn't reproduce it for you, let me know and I'll try again
with the original patch, to reproduce it here: maybe something else
has changed in 2.6.21-rc to affect it.

> 
> Also, does anyone have any thoughts on why x86 uses a ELF_ET_DYN_BASE 
> below the libraries, where as x86_64 uses one above them?  From this, 
> I'd expect x86_64 to collide with the libraries at times.  I need more 
> help understanding the memory layouts, I guess.  :)

Andi would tell definitively, but I guess it's merely that with so
much more address space to play with, x86_64 can divide up that space
more satisfactorily.

But don't be misled: try "ulimit -s unlimited" and I expect you'll
find i386 allocating mmap addresses (hence libraries) from the
opposite end, below ELF_ET_DYN_BASE.

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