On Sun, 2007-11-04 at 00:38 -0500, Brian Kroth wrote: > Ned Ludd wrote: > > On Sat, 2007-11-03 at 23:00 -0500, Brian Kroth wrote: > >>>> 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? > >>> 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? > > > > 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 a > > few 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-vanilla > > bash# . /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.
Does the problem happen still if you do something like this? cp cactid cactid.nopax paxctl -mps cactid.nopax cactid.nopax --verbosity=5 -f 1 -l 10 > 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? The compiler knows when it's building kernel code and should behave appropriately. gcc -dumpspecs | grep -i kernel > Does it also make sense to add -ggdb to the cactid rebuild to try and > pinpoint the failure that way? If you were trying to debug cactid itself then yes. But in this case I think the pax author was trying to pinpoint something else. -- [EMAIL PROTECTED] mailing list
