Ned Ludd wrote:
On Sat, 2007-11-03 at 23:00 -0500, Brian Kroth wrote:I'm using the hardened/x86/2.6 profile which enables the pic use flag. Here's where my understanding gets hazy. PIC != PIE, but the two are related in that PIC creates position independent code, but not for executables? Anyways, how would I check?based on the maps files, both cactid and nagios are PIEs. two questions: are they the only PIEs on this system (that regularly run, that is) and do you have PIEs on the other systems that don't show the symptomps?file, scanelf, readelf..Reading some wikipedia on this now to try and understand it a little better, but it didn't give me any insight as to how to read the maps file to determine whether or not it was a pie.I re-emerged cacti-cactid and did not see pic or pie in the output at all. Is that just enabled by default by the compiler? It looks like it.The profile auto enables USE=hardened on gcc which would result in a compiler that will generate position independent executable with ssp enabled by default. The 'pic' flag is only used in the tree to enable alternative position independent versions of hand written assembly in afew packages or work around other non pic code that we would prefer to be pic otherwise in pkgs.gcc-config gives you the option of switching to various combinations of these flags enabled by the hardened compiler using spec files.For userland debugging it's usually best to switch to the gcc specs to the ones labeled 'vanilla and recompile the programs in question with a command like bash# gcc-config i686-pc-linux-gnu-3.4.6-vanillabash# . /etc/profile ; . ~/.bash_profile See also http://www.gentoo.org/proj/en/qa/backtraces.xml http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml
Excellent. Thanks for the info. So I take it that ET_DYN is a PIE and ET_EXEC is not? If that's the case every other major service on the system seems to be ET_DYN, so no they don't show the symptoms.
I recompiled cactid with vanilla gcc and had it running in a loop for about 10 minutes before it showed a bad page state, which is much longer than usual, but still broken.
So, since at least one of us thinks this is a kernel bug, should I try to compile the kernel using gcc vanilla as well?
Does it also make sense to add -ggdb to the cactid rebuild to try and pinpoint the failure that way?
Brian
smime.p7s
Description: S/MIME Cryptographic Signature
