Re: [gentoo-hardened] Problems emerging glibc-2.3.4.20040619 related to __guard and __stack_smash_handler

> > configure:6211: checking for gcc -fexceptions
> > configure:6224: gcc -no-integrated-cpp -fstack-protector-all -O2 -
> > march=i586 -m3dnow -mmmx -freorder-blocks
> >                 -nostdlib -nostartfiles -fexceptions
> >                 -o conftest conftest.c 1>&5
> > /var/tmp/portage/glibc-2.3.4.20040619/temp/ccgdsRzN.o(.text+0x8): In
> > function `_start':
> > : undefined reference to `__guard'
> > /var/tmp/portage/glibc-2.3.4.20040619/temp/ccgdsRzN.o(.text+0x22): In
> > function `_start':
> > : undefined reference to `__stack_smash_handler'
> > /var/tmp/portage/glibc-2.3.4.20040619/temp/ccgdsRzN.o(.text+0x48): In
> > function `__throw':
> > : undefined reference to `__guard'
> > /var/tmp/portage/glibc-2.3.4.20040619/temp/ccgdsRzN.o(.text+0x62): In
> > function `__throw':
> > : undefined reference to `__stack_smash_handler'
> > collect2: ld returned 1 exit status
> > configure:6227: $? = 1
> > configure:6235: result: no

the above is the result of using -fstack-protector-all (which enables
ssp in gcc and will create the __guard/__stack_smash_handler references)
and -nostdlib that will prevent linking to libc (where these symbols
normally resolv). i wonder how that -fstack-protector-all ended up
there since you're not using a hardened gcc.

> > Oh, and if anyone is still reading this far .. I haven't been able to
> > find docs that explain the impact of Jakub's prelink vs. Pax ASLR.
> > I'm guessing that prelink significantly reduces overall system
> > consumption of RAM (via shared objects using the same memory), while
> > ASLR has the opposite effect?  Or does ASLR only prevent processes
> > from sharing the GOT for shared offset?  I'll find out eventually when
> > I build my next text system and add Pax, and then compare with my
> > current system.  However, I really prefer to understand the reasons
> > more deeply.

prelink doesn't significantly reduce physical memory usage, rather
it speeds up runtime linking (by mapping shared libraries at the same
virtual addresses hence saving on runtime relocation). there will be
some memory savings for shared libraries whose .got is large enough
to spread over several physical pages, but that's hardly measurable
to the .data and other sections (not to mention the stack/heap) that
constitute the major part of a task's physical memory usage (as in,
physical memory that has to be instantiated per task and is not shared
between them).

PaX doesn't affect physical memory usage much, only the stack and the
brk() managed heap will take up to one extra page each. the extra virtual
memory usage is almost the same, one page for the stack and 16 pages
for the brk() heap. what really changes under PaX (and what is at odds
with prelink) is the random start addresses of various address regions
(heap/stack/libs/etc) and the gaps between them (i.e., the maximum size
of a mapping that'd fit in there).


--
gentoo-hardened@g.o mailing list