robert at linuxfromscratch.org
Sun May 13 19:46:55 PDT 2007
Currently, between filtering for -D_LIBC_REENTRANT, -DHAVE_INITFINI, etc, the
Glibc package gets little or no -fstack-protector protection.
In the last few days I have been trying many things, including adding
stack_chk_fail_local.o* to ld.so and libc.so, adding dummy
__stack_chk_fail_local functions to rtld.c, and it's looking like libc.*,
ld.so, and libmemusage.*, can not build with -fstack-protector-all. Before
ssp was moved to TLS, they could. Having stack_chk_guard in TLS is a pretty
good improvement because the guard value is set for each thread, rather than
per program execution, but this also uses far more entropy than before and
makes erandom more important than ever.
If ld.so is compiled with -fstack-protector* it will segfault. I did manage to
build libc.so with -fstack-protector-all, and the test suite passes for
dynamically linked tests, but anything linked to libc.a statically will
crash. This isn't healthy, so the next best thing is to
disable -fstack-protector for ld.so and libc, and use -fstack-protector-all
on the extra-libs and programs. The _FORTIFY_SOURCE protection would have
similar issues, so whereever -fno-stack-protector is, -D_FORTIFY_SOURCE=0
probably also be needed.
The kernel patches for SSP have traditionally used a static guard value, but
with erandom we can use erandom_getbytes from within the kernel. I'm not sure
this will actually add any protection, but it was added to the mainline
kernel for x86_64, so it's worth checking it out again for x86. The patches
and discussion for the x86_64 kernel patch didn't seem to include a proof of
Furthermore, Glibc has designed their SSP code as a debugging feature, not a
security feature. The failure routines could be improved by blocking signals
before doing an abort, and logging to syslog. Gentoo has modified their
stack_chk_guard.c to use inline syscalls, so stack_chk_guard.c doesn't have
any functions itself (so it can compile with -fstack-protector without
causing a circular dependency). Something similar should also be done for all
the files in glibc-2.5/debug/, so _FORTIFY_SOURCE is hardened a bit better.
Doing this with libmudflap would also be a good idea.
I made a new patch for GCC, so pie, ssp, fortify_source, and mudflap
modifications are each separate and optional. Making this work with Glibc is
not difficult... -fno-stack-protector and -D_FORTIFY_SOURCE=0 doesn't make a
difference if you're not using them to begin with. -pie can be detected by
Glibc's ./configure, and so can #ifdef __PIC__. I removed -fpic from the new
GCC patch because pretty much any package that doesn't make their shared
libraries pic needs a patch regardless of whether -fpic is used, so the patch
should add -fpic instead of the GCC specs. This affects a handfull of
graphical packages, like mesa-lib. I'm making sure this patch works with
Glibc before releasing it.
For a wishlist idea, I've also been thinking it'd be nice if SSP could be
disabled on a per function basis, with "#undef __SSP__".
I sent a patch last week to Binutils bugzilla to add --error-shared-textrel.
This is like --warn-shared-textrel, except it causes a fatal error. This
seemed more sensible to me than patching --warn-shared-textrel to be fatal.
It also came to my attention that the '-z lazy' patch doesn't rebuild the
manual and info pages to reflect the new option... but instead of
using --enable-maintainer-mode, the manual and info pages can simply be
removed before building Binutils and they will be rebuilt during 'make' and
will add the new options. I haven't tried this out in the early chapter6
environment, but it should work with Gettext and Texinfo in /tools (it may
need a full install of Gettext).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the hlfs-dev