Re: [gentoo-hardened] kernel upgrade problems: bad page state

[Brian Kroth]

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.

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