| 1 |
On Sun, 2007-11-04 at 00:38 -0500, Brian Kroth wrote: |
| 2 |
> Ned Ludd wrote: |
| 3 |
> > On Sat, 2007-11-03 at 23:00 -0500, Brian Kroth wrote: |
| 4 |
> >>>> based on the maps files, both cactid and nagios are PIEs. two questions: |
| 5 |
> >>>> are they the only PIEs on this system (that regularly run, that is) and |
| 6 |
> >>>> do you have PIEs on the other systems that don't show the symptomps? |
| 7 |
> >>> I'm using the hardened/x86/2.6 profile which enables the pic use flag. |
| 8 |
> >>> Here's where my understanding gets hazy. PIC != PIE, but the two are |
| 9 |
> >>> related in that PIC creates position independent code, but not for |
| 10 |
> >>> executables? Anyways, how would I check? |
| 11 |
> > |
| 12 |
> > file, scanelf, readelf.. |
| 13 |
> > |
| 14 |
> >> Reading some wikipedia on this now to try and understand it a little |
| 15 |
> >> better, but it didn't give me any insight as to how to read the maps |
| 16 |
> >> file to determine whether or not it was a pie. |
| 17 |
> >> |
| 18 |
> >> I re-emerged cacti-cactid and did not see pic or pie in the output at |
| 19 |
> >> all. Is that just enabled by default by the compiler? It looks like it. |
| 20 |
> > |
| 21 |
> > The profile auto enables USE=hardened on gcc which would result in a |
| 22 |
> > compiler that will generate position independent executable with ssp |
| 23 |
> > enabled by default. The 'pic' flag is only used in the tree to enable |
| 24 |
> > alternative position independent versions of hand written assembly in a |
| 25 |
> > few packages or work around other non pic code that we would prefer to |
| 26 |
> > be pic otherwise in pkgs. |
| 27 |
> > |
| 28 |
> > gcc-config gives you the option of switching to various combinations of |
| 29 |
> > these flags enabled by the hardened compiler using spec files. |
| 30 |
> > |
| 31 |
> > For userland debugging it's usually best to switch to the gcc specs to |
| 32 |
> > the ones labeled 'vanilla and recompile the programs in question with a |
| 33 |
> > command like |
| 34 |
> > bash# gcc-config i686-pc-linux-gnu-3.4.6-vanilla |
| 35 |
> > bash# . /etc/profile ; . ~/.bash_profile |
| 36 |
> > |
| 37 |
> > See also |
| 38 |
> > http://www.gentoo.org/proj/en/qa/backtraces.xml |
| 39 |
> > http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml |
| 40 |
> > |
| 41 |
> |
| 42 |
> Excellent. Thanks for the info. So I take it that ET_DYN is a PIE and |
| 43 |
> ET_EXEC is not? If that's the case every other major service on the |
| 44 |
> system seems to be ET_DYN, so no they don't show the symptoms. |
| 45 |
> |
| 46 |
> I recompiled cactid with vanilla gcc and had it running in a loop for |
| 47 |
> about 10 minutes before it showed a bad page state, which is much longer |
| 48 |
> than usual, but still broken. |
| 49 |
|
| 50 |
Does the problem happen still if you do something like this? |
| 51 |
cp cactid cactid.nopax |
| 52 |
paxctl -mps cactid.nopax |
| 53 |
cactid.nopax --verbosity=5 -f 1 -l 10 |
| 54 |
|
| 55 |
|
| 56 |
> So, since at least one of us thinks this is a kernel bug, should I try |
| 57 |
> to compile the kernel using gcc vanilla as well? |
| 58 |
|
| 59 |
The compiler knows when it's building kernel code and should behave |
| 60 |
appropriately. gcc -dumpspecs | grep -i kernel |
| 61 |
|
| 62 |
> Does it also make sense to add -ggdb to the cactid rebuild to try and |
| 63 |
> pinpoint the failure that way? |
| 64 |
|
| 65 |
If you were trying to debug cactid itself then yes. But in this case I |
| 66 |
think the pax author was trying to pinpoint something else. |
| 67 |
|
| 68 |
-- |
| 69 |
gentoo-hardened@g.o mailing list |
Archives