Support source fortification

[ramosian-glider]

Originally reported on Google Code with ID 247

Right now we disable source fortification by defining _FORTIFY_SOURCE=0
This may hide a number of bugs that could otherwise be detected by various _chk functions
(__printf_chk, __strcpy_chk etc.)
A better approach would be to wrap all the _chk functions and let the users enable
source fortification.

A suggestion from Jakub Jelinek:

>Well, -D_FORTIFY_SOURCE=2 does things that asan doesn't and can't do, so
>disabling fortification if you build with -fsanitize=address sounds like 
>a very bad idea to me.
>IMHO libasan should intercept also the __*_chk calls, test + branch to 
>__chk_fail if they should fail, otherwise fall through to the 
>intercepted original function.
>For *printf* family __printf_chk etc. also fail on %n if it isn't in >read-only string
literal.

Reported by ramosian.glider on 2013-11-22 13:48:10

[ramosian-glider]

(see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148)

Reported by ramosian.glider on 2013-11-22 14:39:09

[ramosian-glider]

I think this is becoming more important now that Ubuntu enabled -D_FORTIFY_SOURCE=2
by default. Note that there is not easy way to disable it - passing -D_FORTIFY_SOURCE=0
when -fsanitize=address is active would cause ugly warnings about macro redefinition.

Reported by tetra2005x on 2015-01-14 11:22:36

[ramosian-glider]

Tizen enables -D_FORTIFY_SOURCE by default as well. Looks like this feature has become
very popular...

Reported by tetra2005x on 2015-01-26 09:44:59

[ramosian-glider]

Does it mean that these bugs are out-of-date and clang now supports FORTIFY_SOURCE?
http://llvm.org/bugs/show_bug.cgi?id=18775
http://llvm.org/bugs/show_bug.cgi?id=16821

I guess we should support it then.

Reported by [email protected] on 2015-01-26 10:15:27

[ramosian-glider]

> Does it mean that these bugs are out-of-date
> and clang now supports FORTIFY_SOURCE?

I'm not sure - all my targets use GCC. Simple examples seem to work with TOT Clang
though.

Will you accept libasan patch with fortified interceptors or should we wait until fortification
is stable in Clang?

Reported by tetra2005x on 2015-01-26 10:49:52

[ramosian-glider]

Sure, I don't see any harm in it.

Reported by [email protected] on 2015-01-26 11:52:34

[kcc]

Not working on this.
Please open new bug(s) with more details if needed

[ghost]

Can't file bugs but I'd say the feature is very important. All modern distros enable fortification by default so not supporting this means that we effectively disable checks for memset, memcpy and other extremely interesting functions...

[kcc]

Let's keep it open, although we are still not working on this.

[kcc]

See also: https://sourceware.org/bugzilla/show_bug.cgi?id=20422 (@hannob )
The only reasonable thing is to make sure _FORTIFY_SOURCE is set to 0 when asan/msan/tsan is used.

[sitsofe]

@kcc :

Re sourceware issue 20422: in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148#c4 Jakaob Jelinek suggests there are things that -D_FORTIFY_SOURCE=2 can do that things like asan can't although sadly it's not stated what those are so it could be that other sanitizers cover them. It might be worth asking what those were...

[kcc]

@sitsofe at the very least fortify has more libc interceptors than asan.
The solution to this is not to add interceptors for foo_chk(), but to add interceptors for foo()
or instrument glibc with asan.

[westurner]

Making sure I understand:

• ASan is functionally similar to FORTIFY_SOURCE
• Things break when FORTIFY_SOURCE and ASan are both enabled
• Ideally, we could have both FORTIFY_SOURCE and asan
  • The decision made here is that asan is preferable to FORTIFY_SOURCE?
  • Is there a different issue discussing how to make FORTIFY_SOURCE and asan compatible?
• Is memory sanitizer incompatible with _FORTIFY_SOURCE=2? #689 has some test code

[westurner]

Should production builds choose FORTIFY_SOURCE (edit) FORTIFY_SOURCE=2?

Should debug builds choose asan?

[yugr]

ASan is functionally similar to FORTIFY_SOURCE

In general yes but Asan is much more precise (and slower). It's preferred choice for debugging purposes (with -U_FORTIFY_SOURCE to disable fortification). Fortification is preferred for production builds though.

Things break when FORTIFY_SOURCE and ASan are both enabled

FORTIFY_SOURCE (which is enabled by default in modern distros) prevents Asan from detecting some types of bugs.

Ideally, we could have both FORTIFY_SOURCE and asan

Yes.

Is there a different issue discussing how to make FORTIFY_SOURCE and asan compatible?

The "how" has been discussed on GCC mailing list few years ago, try searching there.

[jiridanek]

Workaround is to compile with -Wp,-U_FORTIFY_SOURCE appended at the end of CFLAGS.

When there is annobin at play (RPM builds, or if you set your default CFLAGS by running eval "$(rpmbuild --eval '%set_build_flags')"), use -Wp,-U_FORTIFY_SOURCE -fplugin=annobin -fplugin-arg-annobin-no-active-checks to both disable fortification and tell annobin not to complain about it.