stability of fortify source

Kevin Day thekevinday at
Sat Jul 4 07:44:02 PDT 2009

On Sat, Jul 4, 2009 at 7:18 AM, thorsten<fly_b747 at> wrote:
> Good day to everyone!
> Within the last months i built a hardened system including PIE, stack
> protector, bind now, grsec and fortify source including X and firefox. A
> firefox compiled with fortify source crashes while stating up. compiling
> firefox with fortify source disabled results in a firefox which crashes
> at seemingly random times (ie. moving tabs, about:plugins ...). running
> firefox within gdb shows crashes within system libs. unfortunately my
> system does not have debugging symbols so the crashes are hard to track
> down.
> I begin to suspect fortify source as beeing the reason for these
> instabilities. Within the next weeks I am going to build a system
> without fortify source to investigate this further.
> Has anybody an opinion regarding this?
> Thorsten

Problems like these happened a couple years ago when SSP was rather new.
It turns out most of the code used out there was simply not programmed
well and many memory leaks were going on.
SSP would then abort the program.
Aborting looks the same as a crash to an end-user. (and might as well
be the same)
Since gcc's adoption of SSP mainline and since major distro's picked
up using SSP, numerous projects started to clean up some of their

I would not be surprised that poorly designed code is still the issue
when it comes to FORTIFY_SOURCE.

Another possibility is PIE.
This also has historically caused problems.
Back then it was rather new as well and there was much ASM code that
didn't like PIE to well.
(particularly with Xorg & Mesa, but that is long fixed now I believe)

The final major possibility is grsec. This one is probably the least
likely but also the easiest to confirm.
Try building a kernel without grsecurity first and boot the existing
problematic system.
Then you will easily know if grsecurity is the issue.

Kevin Day

More information about the hlfs-dev mailing list