propolice testsuite

Robert Connolly robert at linuxfromscratch.org
Sat Oct 23 07:52:08 PDT 2004


The newest patch from ibm seems to work better, at least the testsuite passes. 
It has a new configure option added "--enable-stack-protector" which makes 
-fstack-protector the default. New internal defines too, here's an example:

$ cat > conftest.c << "EOF"
int main () {
#if __SSP_ALL__ == 2
        printf("-fstack-protector-all is default.\n");
#else
#if __SSP__ == 1
        printf("-fstack-protector is default.\n");
#else
        printf("__SSP__ is not defined\n");
#endif
#endif
}
EOF

$ gcc -o conftest conftest.c
$ ./conftest
-fstack-protector is default.

$ gcc -fstack-protector-all -o conftest conftest.c
$ ./conftest
-fstack-protector-all is default.

As per the latest changelog on:
http://www.trl.ibm.com/projects/security/ssp/

The "--enable-stack-protector" seems to be much like the protector_only patch 
from before. It does not set the version.c string (we still need to by hand), 
but the "--enable-stack-protector" switch shows up in `gcc -v`. I used it 
with `make bootstrap` and `make -k check` gave the same results as if I 
didn't use the patch at all; But:

$ objdump -d /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.2/libgcc.a \
	| grep smash
_stack_smash_handler.oS:     file format elf32-i386

If I remember correctly this looks like libgcc.a is contaminated and will 
cause a failure in Glibc's testsuite in chapter 6 (libgcc will cause a stack 
overflow). So maybe using "--enable-stack-protector" isn't a hot idea, not to 
mention -fstack-protector-all is what we want to use anyway.

I've been thinking a lot about the Binutils TLS failures (caused by PIE and 
GCC), which led me to think about the sspspecs and piespecs patches. This 
method of editing the gcc specs file, while convenient, has always caused me 
one problem or another.

For example to prevent libgcc.a from getting -fstack-protector-all (and smash 
symbols) I have been using the !DIN_GCC filter, but as a side effect gcc 
itself was skipped too; and the !D_LIBC_ filter would prevent libc.so from 
getting ssp and pie flags. The -fpie gcc flag hasn't been being use at all 
because it has issues with a small handfull of programs.

The -fstack-protector-all, -fpie, and -pie flags should only be used on 
executable binaries, not libraries, but there is no `gcc -binary` or `gcc 
-library` switches to be able to filter these perfectly. My new thoughts are 
to patch *everything* (almost), to surgically use these flags exactly where 
needed. Obsd does this to an extent, they have patched everything for 
-fno-stack-protector where needed, but I propose both the on and off switches 
so the patches will work regardless of the default behaviour of gcc or its 
specs file. More specificly I'm thinking to make a "--with-ssp=yes" autoconf 
test which can be used at the discretion of upstream developers and other 
distributions. This isn't exactly difficult, its just time consuming. After 
patching for "--with-ssp" I think the exact same thing should be done for 
"--with-pie". I think this is the best way.




More information about the hlfs-dev mailing list