[CFdiscussion] ports and FORTIFY_SOURCE

Pedro Giffuni pfg at FreeBSD.org
Wed Sep 2 16:19:54 UTC 2015


Hello;

On 09/02/15 10:12, Baptiste Daroussin wrote:
> On Mon, Aug 31, 2015 at 01:34:06PM -0500, Pedro Giffuni wrote:
>> Dear ports developers;
>>
>> This year I mentored Oliver Pinter's GSoC project [1] to port
>> FORTIFY_SOURCE to FreeBSD. The project was more complex than we
>> thought initially but it was successful.
>>
>> For those of you that haven't heard of it, it's a trick supported by
>> libc to enable bounds-checking on common string and memory functions.
>> The code has gone through extensive testing with both clang and the
>> base gcc. It should work fine with newer gcc but it is untested there.
>>
>> To activate it you will just need to add -D_FORTIFY_SOURCE=1 (or 2) in
>> the CFLAGS and that will transparently add the extra checks. The code
>> is non invasive but some ports (firefox, emacs) actually choose to run
>> with this flag on by default and an exp-run found some errors in those
>> cases.
>>
...

>> In the future it would be nice to support a flag within ports to enable
>> or disable this extra flag for specific ports. I am unsure exactly how
>> to do it, it could be something as simple as
>>
>> USE_FORTIFY=	yes
>> or as complex as
>> USES= 	compiler:fortify=0
>> (0 disables it, 1 is standard for clang. 2 is standard for gcc)
>>
> IMHO it should be done the exact same way as SSP was added. meaning always
> activated and ports that are not playing safely with it should explicitly
> disable it via:
> FORTIFY_UNSAFE=yes
>
> and a WITHOUt_FORTIFY (like we have a WITHOUT_SSP) should be added for people
> willing to entirely remove it.
>

Well, our fortify is a little more strict than the linux implementation
so I am afraid that if we just go ahead and activate it for everyone we
would have new failures. With clang such failures sadly only happen
during runtime.

There would be no false positives, all real bugs, but we would get 
complaints in the lines of "this program works on *OtherOS* and
FreeBSD 10 but it core dumps on FreeBSD 11 so you surely FreeBSD 11 is
unstable/broken.

It would be certainly interesting to be more aggressive, but I would 
recommend doing it gradually: at the very least we should do a new
exp-run with FORTIFY_SOURCE fully enabled.

The other issue is that debugging you will find a lot of references to
__strcpy_chk and other bounds-checking replacement functions. When we 
get to the point where the new tool doesn't detect any bugs it makes
no sense to cause these annoyances.

Just my IMHO of course,

Pedro.


More information about the freebsd-ports mailing list