Exec-shield and memory randomization

Juho Snellman jsnell at iki.fi
Fri Aug 5 03:12:13 UTC 2005


<roland at redhat.com> wrote:
>> Still, this is rather unfortunate as there seems to be no reasonable way
>> to get the ELF loader to reserve memory ranges.
>
> The specified way is to use a PT_LOAD segment with p_flags 0, yielding a
> PROT_NONE mapping that your program can mmap over or munmap after startup.
> If this does not work right, then please file a bug about it.

I don't feel it's a reasonable solution. (But I recognize that others
might think I'm being unreasonable here).

  * Linker scripts are too fragile. You can't specify "use the
    internal default script, but add this PHDR and this section", so
    you need to copy the default, munge it in strange ways to actually
    make it work, and then hope that the next glibc/binutils/etc
    update doesn't break the script. We've had problems like this 
    with the linker script on the platform where we're forced to use it
    for other reasons.

    Case in point, the script you posted a couple of years ago at
    <http://lists.gnu.org/archive/html/mit-scheme-devel/2003-11/msg00009.html>
    doesn't work any more, but requires moving the "required" PHDR
    below the other two PT_LOADs, and adding a FILEHDR option to it.
    This seems like a bizarre change, but that's the only way the script
    would accept more than two PT_LOADs.
    
  * @nobits PT_LOADed segments don't just reserve the address space,
    but also count as allocated space for overcommit purposes (with
    the default 0 in /proc/sys/vm/overcommit_memory) unlike memory
    allocated with mmap. (Apparently because the protection bits are
    discarded, http://bugzilla.kernel.org/show_bug.cgi?id=2255)
    
    We need to reserve large spaces and also run on low-memory
    machines.
    
  * Even if both of the above problems were to be fixed in the next
    release of FC, we'd still need to find a solution that also works
    on older Linux installations.

The other common suggestion of writing/borrowing a ld.so replacement
doesn't seem much more palatable.

-- 
Juho Snellman




More information about the fedora-devel-list mailing list