[lkml]   [2004]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Potential bug in fs/binfmt_elf.c?
    Hash: SHA1

    Mike Hearn wrote:

    > LOAD 0x000000 0x00000000 0x00000000 0x00bc4 0x00bc4 R E 0x1000
    > LOAD 0x000bc4 0x00000bc4 0x00000bc4 0x00150 0x00154 RW 0x1000
    > DYNAMIC 0x000bd0 0x00000bd0 0x00000bd0 0x00108 0x00108 RW 0x4
    > LOAD 0x001000 0x00400000 0x00400000 0x00000 0x10000000 R 0x1000

    Not everything which can be expressed in ELF is supported. You don't
    want to load something, you want to reserve address space. And you want
    it allocated in a certain way. The ELF loader is no generic ELF

    Now, if the only problem is the overcommit and making the do_brk() call
    allocate the memory as read-only a change to the do_brk() interface
    might be acceptable (well, ask somebody doing mm hacking). I wouldn't
    be entirely sure whether read-only pages alone are enough. This does
    not open any new holes as far as I can see.

    I'd say experiment with it and add a flags parameter which is the right
    combination of VM_READ | VM_WRITE | VM_EXEC. All calls but the one in
    binfmt_elf.c should pass all read bits, the one in binfmt_elf can
    respect the binaries flags. You must be sure, though, that the last
    page of the data area (i.e., writable area) in a regular binary is not
    mapped read-only.

    - --
    ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
    Version: GnuPG v1.2.3 (GNU/Linux)

    -----END PGP SIGNATURE-----
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:01    [W:0.023 / U:1.984 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site