Re: amd64/linux/redhat lib memory map for 32 bit apps (task_unmapped_baseetc.)

From: Eric Taylor (et1_at_rocketship1.com)
Date: 02/28/04

  • Next message: Pete Zaitcev (OTID1): "Re: Modify USB driver for fixed tty port mapping" 
    Date: Sat, 28 Feb 2004 02:16:46 GMT

    Thans for the tip on exec-shield. It brings up a few questions.

    1. Since you mentioned this was turned on in Fedora, is it also part of
    the amd64's 32 bit support. With the amd64, I was hoping to get
    as much contiguous sbrk as possible, including the extra 1 gig normally
    allocated for the 32 bit kernel.

    2. If I have my own .so library, which I want to change between runs of
    a program, might the memory layout - esp. the sbrk start, be in a different
    place? Is there a way to build a .so library so it always loads in high virt
    addresses, while forcing ld-linux.so into the low memory zone?

    3. I have an enterprise version of redhat on our amd64, since I don't see this
    occuring there, I take it this does not have the exec-shield code yet.

    4. Is this exec-shield related to the code I saw in mmap.c that determines
    where a .so loads? That code I've only seen is some variants of kernels
    that come with the source on a redhat installation cd. It seemed that it
    would load .so's at a different base than TASK_UNMAPPED_BASE
    each time a program ran. I once saw a comment that indicated this
    was a security idea being used by redhat.

    Our situation is somewhat unique. We run long running simulations with
    our own memory allocator (i.e. not malloc) that uses sbrk exclusively. We
    need to be able to checkpoint the program (sbrk area and stack), build a
    new .so and then restart the simulation where it left off, but with changes to
    some code in our .so library. We call this checkpoint/modify/restart. The
    checkpoint is rather simple, one write of the entire sbrk region, and one of
    the stack. Restore is an opposite read. As long as our .so library is loaded
    above the sbrk region, and below the stack (we use very little stack) this
    works. Any .so that did not change, like ld-linux or libc would be ok to
    load below the sbrk area.

    Also, we can't easily modify this behavior, since the software we are using
    that handles all this memory managing is a proprietary product
    (a simulation language called simscript).

    In the past, we have moved TASK_UNMAPPED_BASE and built a
    custom kernel. The problem with this is our customer(s) keeps changing
    hardware, and does not want to build custom kernels with a patch. Each
    time I build a kernel for their hardware, it only lasts until their next hardware
    purchase. We were hoping to get out of the kernel patching business for
    this reason.

    John Reiser wrote:

    > > ... I can't figure out
    > > what makes it load in different places depending on how you start up.
    >
    > The code is in fs/binfmt_elf.c inside the Linux kernel.
    >
    > Under Fedora Core 1 for x86, the "exec shield" feature is turned on. One of
    > the effects is that ET_DYN modules with a PT_LOAD that has PF_X permission
    > get placed in the region [1MB, 16MB) if possible. This includes ld-linux.so.2
    > and libc.so.6. Also, if the a.elf has a GNU_STACK .p_type, then any mmap()
    > that does not ask for PROT_EXEC (and not MAP_FIXED, either) gets placed as
    > high as possible: such regions "pile up" just below the stack. As a result
    > of these two policies, nearly as much contiguous address space as possible
    > is left vacant. [glibc and malloc must cooperate, too, of course; you might
    > have to diddle malloc's policy about using mmap(0, ...) in certain cases.]
    > So try enabling exec shield, if possible. See http://lwn.net/Articles/31033/
    >
    > --

  • Next message: Pete Zaitcev (OTID1): "Re: Modify USB driver for fixed tty port mapping"