Re: Potential bug in fs/binfmt_elf.c?

[Mike Hearn]

On Sat, 06 Mar 2004 22:11:18 -0800, Ulrich Drepper wrote:
> 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
> interpreter.

Ah, OK. I was hoping this would not the answer.
 
> 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.

This is certainly one long term solution, but we'd like to avoid kernel
hacking if at all possible. We have a prototype of a program which is
statically linked then turns itself into a dynamically linked app by
bootstrapping the ELF interpreter in the same way the kernel does after
mapping the range wanted with MAP_NORESERVE. Obviously we'd like the real
fix, but something which works nicely on Fedora Core 1 machines today is
also necessary.

Thanks for your advice. One quick question - you said binfmt_elf is not a
generic ELF interpreter, but the one in glibc presumably is yes? Would it
be possible to achieve the effect wanted by having a dummy stub binary
linked with -nostdlib etc, so it's a dynamically linked ELF program with
only one DT_NEEDED entry which is against the real binary.

This would short-circuit the kernel loader and pass control as soon as 
possible to glibc, which would follow the first DT_NEEDED entry and map in
the real binary, which in turn contains the PE load area reservation
section. IIRC glibc always uses mmap to map ELF sections so this could
work better.

Does this sound plausible? If so, do you have any tips on where to look
for docs on it? Last time I tried compiling something with -nostdlib, I
ran into problems with the default linker script not liking it (entry
points I think).

thanks -mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/