Hallo! On Tue, 17 May 2011 11:31:37 +0200, Svante Signell <s...@kth.se> wrote: > Further info. I think the problem is with gcc-4.6 mis-compiling.
Well, that's not quite right. But it's not very wrong either...
> (Another issue is the memora acces problems in gdb: bothe present with
> gcc-4.4 and gcc-4.6).
>
> Building exim-4.75-3 with gcc-4.6 -O2 results in a segfault:
> (even though the packages are successfully built: debian/minimaltest
> script is only present in 4.76-1)
>
> gdb build-tree/build-exim4-daemon-{light,heavy}/exim
>
> (gdb) run
> Starting program: exim4-4.75/build-tree/build-exim4-daemon-light/exim
> Cannot access memory at address 0x726f2030
> Cannot access memory at address 0x726f2030
> [...]
I can reproduce all of this. The ``problem'':
$ grep HARDENING debian/rules
export DEB_BUILD_HARDENING=1
#export DEB_BUILD_HARDENING_FORTIFY=0
This has, according to debian/changelog, recently been enabled. I took
notice of this package when I ran ``apt-get build-dep exim4'' this
afternoon.
$ apt-cache show hardening-wrapper
Package: hardening-wrapper
Version: 1.32
Installed-Size: 116
Maintainer: Package Hardening <hardening-disc...@lists.alioth.debian.org>
Architecture: hurd-i386
Depends: gcc | g++, perl
Description: Compiler wrapper to enable security hardening flags
Replaces gcc, g++, and ld with wrapper scripts that set security
hardening
compilation flags, as an alternative to changing gcc specs. Enabled
when
DEB_BUILD_HARDENING=1 is set.
Homepage: http://wiki.debian.org/Hardening
[...]
Apparently there's something going very wrong for us, for some of the
hardening flags, such that GDB gets confused, SEGFAULTs arise, and all
what we've seen. Svante, sorry, I really didn't expect something like
that... (Welcome to the wonderful world of debugging.) The reason I
don't know yet. Perhaps some GCC specs oddity. Or something in glibc/in
the dynamic linker.
Change that flag to DEB_BUILD_HARDENING=0, and exim4's mini-testsuite
will pass.
I can also tell you why the build didn't SEGFAULT on the Debian buildd:
the testsuite is only run if the Debian-exim user exists (in
/etc/passwd), and that one only exists if the exim4-config package is
installed -- which it probably isn't on the buildd.
Next step, I: Upload a thusly-fixed exim4 to debian-ports? (So that the
Debian Installer is usable again.)
Next step, II: Figure out what's going wrong. Svante, interested? I
would begin as follows.
Figure out which hardening flag is the culprit. For this, leave
DEB_BUILD_HARDENING_FORTIFY=1 set, but disable individual flags until it
succeeds. /usr/bin/hardened-cc defines the following defaults:
DEB_BUILD_HARDENING_STACKPROTECTOR=1
DEB_BUILD_HARDENING_FORTIFY=1
DEB_BUILD_HARDENING_FORMAT=1
DEB_BUILD_HARDENING_PIE=1
You can override these by putting [...]=0 into debian/rules.
The Stack Protector should be fine. Fortifying I don't know. Format I'd
expect to be OK. PIE I don't know -- has this ever been tested for
anything? This testing is easily done with our friend exim4.
In parallel, you could test this with some tiny test program that is more
quickly built than exim4: a C file with a main function that calls, for
example, stat on some file (see ``man 2 stat'' for an example). Build it
like this:
$ DEB_BUILD_HARDENING=1 gcc -Wall -g -O2 -o hardened file.c
$ ./hardened [...]
This one should SEGFAULT. If not, you need another test program.
$ gcc -Wall -g -O2 -o normal file.c
$ ./normal [...]
This one should work fine.
$ DEB_BUILD_HARDENING=1 DEB_BUILD_HARDENING_PIE=0 gcc -Wall -g -O2 -o
hardened-no-PIE file.c
$ ./hardened-no-PIE [...]
This one we don't know. Try to figure out if there's a single
DEB_BUILD_HARDENING_* flag that toggles the behavior.
With the same method you can try to figure out which flag it is that
confuses GDB. Might be the same one that triggers the SEGFAULT, might be
something else.
Grüße,
Thomas
pgpfuvWkPpdrU.pgp
Description: PGP signature
