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

[Brandon Hale]

On Sun, 2004-07-18 at 09:22 -0700, wrote:
> What do I need to do differently to emerge glibc-2.3.4.20040619?
>
> I recently emerged gcc 3.3.4-r1, WITHOUT the 'hardened' flag.  I'm
> trying to get everything compiled with ssp, but without ASLR (due to
> memory consumption concerns) for the moment.  From config.log in
> glibc, I see that one of configure's tests failed, due to -nostdlib
> excluding the definitions for __guard and __stack_smash_handler.  This
> caused glibc to think that -fexceptions fails for my gcc, later
> leading to failure when building libio.

By "without ASLR" I imagine you mean one of two things. Either you mean
without PIE, which helps ASLR, or literally without ASLR, which is part
of the kernel and has nothing to do with GCC.

With the first, I'll admit that PIE executables seem to be slightly
larger (acceptably, imo). but I am not aware of an additional strain on
memory. Correct me here, Solar?

Are you passing -nostdlib in CFLAGS, or is that coming from the Makefile
in this following bit? Please file a proper bug report with this log and
`emerge info`, along with any other relevant information to
http://bugs.gentoo.org/
Thanks :)

> 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
>
> From http://www.gentoo.org/proj/en/hardened/propolice.xml, I see notes
> that __guard and __stack_smash_handler are moving(ed?) elsewhere, but:
>
> # readelf --syms /lib/libc-2.3.3.so | grep stack_smash
>    336: 0001596e   485 FUNC    GLOBAL DEFAULT   11
> __stack_smash_handler@@GLIBC_2.3.2

This move was many months ago now. It moved from libgcc to libc.

> Now I can't find any relevant links on the hardened Gentoo "homepage"
> for ASLR, propolice, hardened gcc, etc, so I'm wondering what docs I
> should be reading instead of posting here?  I noticed that Google
> doesn't even show pages linking to the propolice.xml page I listed
> above.  ???

hardened-gcc as a package is deprecated in favor of USE=hardened gcc.
The other missing docs were very much outdated, and are still around,
but no longer linked to due to lack of relevance to the current
toolchain. I'm looking for help to rectify this situation.

Again with ASLR... Documentation both on what ASLR actually is (a
function of PaX), and also on ET_DYN, the original conception of PIE
(binaries linked for position independence in memory at runtime) can be
found on the PaX homepage, http://pax.grsecurity.net/

The current implementation in our toolchain (PIE) is similar to ET_DYN
conceptually, but implemented later, largely by RedHat and input from
other players. You'll want to look around the toolchain mailinglist
archives.

Further documentation on SSP (-fstack-*) can be found at the project
page hosted by IBM. 
http://www.trl.ibm.com/projects/security/ssp/

> Thanks for any and all tips, especially links so I can go RTFM .. or
> is the answer RTFC (C=code)?
>
> 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.

The question you pose here gets pretty deep into the guts of the linker,
and PaX's ASLR, which I admitedly don't understand enough to touch this.
Perhaps the PaX Team would be kind enough to shed some further light on
this subject.

> Thanks to all for the awesome hardened Gentoo flavor!

Thanks for playing along, I hope I've answered a few of your questions.
Brandon Hale


--
gentoo-hardened@g.o mailing list