[uClibc] Re: [grsec] crt1S.S file for uClibc

pageexec at freemail.hu pageexec at freemail.hu
Tue Oct 14 20:01:39 UTC 2003

> I do not have any problems with CTOR_DTOR and dynamic atexit, either with 
> threads and shadow.

can you send me your crt1.o file please? i can't imagine how
it can be properly created given the bug in initfini.awk.

> See the attached config file (this works).

unfortunately i got an error with it when i ran make

# using defaults found in .config
make: *** [menuconfig] Error 1

in any case, i know now that it's the UCLIBC_CTOR_DTOR option which
triggers the bug:

initfini.awk splits up initfini.S into crti.S and crtn.S. these
files contain among others the epilogue and prologue code for _init
and _fini, respectively. the problem is that the epilogues contain
garbage code which causes an early termination (return from) the
given functions without properly cleaning up the stack and hence
execution flow ends up in some data segment and gets killed under
PaX or causes a SIGSEGV otherwise. the garbage code in question is
nothing else but the helper function used in PIC self-position
calculation. this helper code gets emitted just before the
prologue normally but due to the bug it ends up in the epilogues
as well.

what goes into crtn.S is controlled by the 'omitcrtn' variable in
the awk script. i believe the problem is that it is set/reset at
the wrong place. in particular, this line is wrong:


by the time the lines matching this are emitted, it's too late,
the PIC helper function has been emitted into crtn.S as well
and will cause premature function return.

my suggested fix is to use this instead the above line:

/_init_PROLOG_BEGINS/{omitcrti=0;print ".section .init" >> "crtn.S";getline}
/_fini_PROLOG_BEGINS/{omitcrti=0;print ".section .fini" >> "crtn.S";getline}

this will just emit enough information to set the correct sections
in crtn.S as well (which was the original intention i guess).

> Looking at the crt0.S file, it looks
> like we need L_crt1 and __UCLIBC_CTOR_DTOR__ defined, else the crt1S.S 
> provided by the PaX Team cannot work, or it requires changes in 
> libc/misc/internals/__uClibc_main.c file.

FYI, i didn't change any logic in the crt0.S file, that is,
the exact same symbols are referenced/provided, my changes
affect only how they are retrieved. in the original they are
resolved at link time and hence end up as a hardwired value
and cause text relocations when linked into an ET_DYN
executable, in my version i get them from the .got at runtime.

More information about the uClibc mailing list