From: silvio@big.net.au
Date: 09/30/02

From: silvio@big.net.au (silvio@big.net.au)
Date: Mon, 30 Sep 2002 01:00:03 -0700

On Mon, Sep 30, 2002 at 07:40:00AM +0100, Dave Wilson wrote:
> On Sun, Sep 29, 2002 at 10:03:36PM -0700, silvio@big.net.au wrote:
> > #include <stdio.h>
> > int main(int argc, char *argv[]) { char *v[] = { NULL };
> > execve(argv[1], v, NULL); }
> This is the linux glibc bootstrap code behaviour. main() is never
> reached. It's not new either.
thanks for the descriptive information! -->

(for linux ia32)
can you provide more details on this? I'm not seeing this behaviour on
glibc 2.1.3 and 2.2.4, and at least the code for 2.1.3 verifies this
quite well (ignoring the __libc_start_main never going to happen argc + 1,
integer overflow if you ever get argc to be fully controllable - not on linux
at least.. might want to check other systems). glibc 2.2.x has changed
the __libc_start_main code a bit (start.S for i386 looks the same), so
i manually tried some code on a rh 7.2 box - which doesnt
have startup code crashes you talk about. From my tests, it passes control
into main from __libc_start_main ok.
there is some debugging output which uses argv[0] in __libc_start_main,
but this can be ignored.

is this linux your talking about, or some other system? i have not
been able to reproduce the behaviour you describe, but i do not know the
code that well, and only am using linux ia32.

> > This is of course, not really a security threat by any means.. It is an
> > annoying bug that effects alot of things and is really not handled
> > correctly in the majority of implementations.
> How about not misusing exec()? 'course not, let's patch our kernels to
> stop idiots from using exec()!!

i think maybe a kernel patch is the best place for this.. its not fantastic
I agree, but is probably the best solution. Do the single unix specs or
something have anything to say of what is standard behaviour here? - ie,
kernel or user space problem.


if you really know what your talking about.. can you actually say what
versions its effecting.. because i cannot see which version of
glibc code your talking about here! and "glibc bootstrap code".. seriously,
what does that mean? i'm really only thinking of _start or __libc_start_main
at this point, unless your refering to some sort of whack rtld issue, or
kernel -> rtld issue, which i dont see is going happen. lets not even
get into code that doesnt link against libc



Relevant Pages

  • Re: Newbie question about kernels
    ... >> Sheesh. ... This leads to a slightly smaller and slightly faster glibc (and, ... excellent and incredibly scalable threading implementation for Linux 2.6 ... glibc will be automatically used whenever an appropriate kernel is ...
  • understanding linux
    ... As far as i now linux works on many different platforms. ... that every plattform ... neccessary to compile the kernel?? ... is the source of glibc also open-source? ...
  • Re: Type conflicts in in.h header files.
    ... I don't know anything about multicast routing on Linux, ... Each of those headers defines those symbols in an enum, ... core glibc header a superset of that in the glibc kernel header. ...
  • man-pages-3.25 is released
    ... I've released man-pages-3.25.tar.gz - man pages for Linux ... These flags (used for Kernel Samepage Mergeing, ... These functions are new in glibc 2.11. ... Michael Kerrisk ...
  • Re: can one produce a complete statically build application using gfortran on linux platform?
    ... is NOT possible to actually make a 100% statically link program on ... and thus glibc sort of follows that philosophy as well. ... But since all Linux systems will have glibc.so ... interpreting OpenGL function calls and sending appropriate ...