[Fwd: randomize_va_space default change?]

Dave Roberts ldave at droberts.com
Fri Jul 29 01:17:44 UTC 2005


I originally sent this to the Fedora users list earlier this morning but
didn't get a single response as of this evening. Upon reflection, it
seemed like a good idea to send this to the developers list.

If anybody can point me to a comprehensive explanation of all the
various exec-shield technologies and the ways they interact with
different kernel versions, gcc versions, etc., I would be happy to RTFM.
As of now, Googling had just returned various bits and pieces, many of
which already seem out of date as exec-shield has evolved and gotten
into upstream kernel work.

-- Dave

-------- Forwarded Message --------
From: Dave Roberts <ldave at droberts.com>
Reply-To: For users of Fedora Core releases <fedora-list at redhat.com>
To: For users of Fedora Core releases <fedora-list at redhat.com>
Subject: randomize_va_space default change?
Date: Thu, 28 Jul 2005 11:08:11 -0700
Did something just change with one of the latest kernel releases for FC3
to enable randomize_va_space by default? I had a program (sbcl - Steel
Bank Common Lisp) that was working fine with previous kernels and now
seems to be having trouble with address space randomization.

Either that, or was there a setting change in gcc that now defaults to
allowing randomization in some ELF header bit somewhere? Perhaps in gcc
3.4.3 or thereabouts? I have noticed that binaries built after sometime
in May suffer from the problem but older binaries don't. Further, newer
binaries didn't start suffering until running them with recent kernels
and/or glibcs.

I'm having a lot of trouble finding information about how
randomize_va_space works. Setting it to 0 in /proc/... works fine, but
I'd rather have some way to build sbcl such that I can mark it as
incompatible with address space randomization rather than turning off
this feature for the whole system. I know that other exec-shield
features have ELF bits that can be flipped with build options, but they
seem to default to being off for compatibility's sake.

-- 
Dave Roberts <ldave at droberts.com>

-- 
Dave Roberts <ldave at droberts.com>




More information about the devel mailing list