Support source fortification #247

ramosian-glider · 2015-08-31T22:09:15Z

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

The text was updated successfully, but these errors were encountered:

ramosian-glider · 2015-08-31T22:09:23Z

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

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

ramosian-glider · 2015-08-31T22:09:41Z

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 · 2015-08-31T22:09:49Z

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 · 2015-08-31T22:09:58Z

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 eugenis@google.com on 2015-01-26 10:15:27

ramosian-glider · 2015-08-31T22:10:07Z

> 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 · 2015-08-31T22:10:16Z

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

Reported by eugenis@google.com on 2015-01-26 11:52:34

kcc · 2015-12-01T23:40:11Z

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

ghost · 2015-12-03T10:27:13Z

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 · 2015-12-03T20:50:27Z

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

kcc · 2016-08-24T23:25:37Z

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 · 2016-08-25T06:01:23Z

@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 · 2016-08-25T06:34:27Z

@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.

Sanitizers and fortifications do not interface, and there is currently no plan for them to work together. See also google/sanitizers#247

westurner · 2019-12-06T12:14:42Z

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 · 2019-12-06T12:18:53Z

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

Should debug builds choose asan?

yugr · 2019-12-06T12:49:02Z

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.

Bug: bazelbuild/bazel#6932, google/sanitizers#247

jiridanek · 2022-10-19T06:32:37Z

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.

Related: google/sanitizers#247 (comment)

...because ASAN does an extended version of this, and it's said to produce wrong results with fortification. Bug: google/sanitizers#247 Change-Id: Ia4bbbf96a1c82ee76c332a0136e3f9e44af1f724

Add support for clang Memory Sanitizer [1], which detects the usage of uninitialized values. While elfutils itself is already checked with valgrind, checking code that depends on elfutils requires elfutils to be built with MSan. Unlike the other sanitizers, MSan needs to be configured fairly early, since we need to drop -D_FORTIFY_SOURCE [2], -Wl,-z,defs and --no-undefined. [1] https://clang.llvm.org/docs/MemorySanitizer.html [2] google/sanitizers#247 Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>

Add support for clang Memory Sanitizer [1], which detects the usage of uninitialized values. While elfutils itself is already checked with valgrind, checking code that depends on elfutils requires elfutils to be built with MSan. MSan is not linked into shared libraries, and is linked into executables statically. Therefore, unlike the other sanitizers, MSan needs to be configured fairly early, since we need to drop -D_FORTIFY_SOURCE [2], -Wl,-z,defs and --no-undefined. Disable a few tests that run for more than 5 minutes due to test files being statically linked with MSan. [1] https://clang.llvm.org/docs/MemorySanitizer.html [2] google/sanitizers#247 Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>

Related: google/sanitizers#247 (comment)

Add support for clang Memory Sanitizer [1], which detects the usage of uninitialized values. While elfutils itself is already checked with valgrind, checking code that depends on elfutils requires elfutils to be built with MSan. MSan is not linked into shared libraries, and is linked into executables statically. Therefore, unlike the other sanitizers, MSan needs to be configured fairly early, since we need to drop -D_FORTIFY_SOURCE [2], -Wl,-z,defs and --no-undefined. Disable a few tests that run for more than 5 minutes due to test files being statically linked with MSan. [1] https://clang.llvm.org/docs/MemorySanitizer.html [2] google/sanitizers#247 Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>

Related: google/sanitizers#247 (comment)

…and MSAN This can cause either false positives in warnings from the compiler or false negatives where the sanitizer misses something. Bug: google/sanitizers#247 Signed-off-by: Sam James <sam@gentoo.org>

This can cause either false positives in warnings from the compiler or false negatives where the sanitizer misses something, so don't default-enable FORTIFY_SOURCE when -fsanitize=address is set to be safe. Bug: google/sanitizers#247 Signed-off-by: Sam James <sam@gentoo.org>

…bled This can cause either false positives in warnings from the compiler or false negatives where the sanitizer misses something. Bug: google/sanitizers#247 Signed-off-by: Sam James <sam@gentoo.org>

ramosian-glider assigned google Aug 31, 2015

ramosian-glider added ProjectAddressSanitizer Type-Enhancement Priority-Low Status-New labels Aug 31, 2015

kcc closed this as completed Dec 1, 2015

kcc reopened this Dec 3, 2015

sitsofe mentioned this issue Jun 14, 2016

Is memory sanitizer incompatible with _FORTIFY_SOURCE=2? #689

Closed

willwray mentioned this issue Aug 10, 2016

Remove _FORTIFY_SOURCES from build: XRPLF/rippled#1812

Closed

Lekensteyn mentioned this issue Sep 6, 2016

False positive with use of longjmp in an external library and FORTIFY_SOURCE #721

Closed

sitsofe mentioned this issue Nov 17, 2016

Please merge FORTIFY_SOURCE FAQ answers #743

Closed

james-d-mitchell mentioned this issue Jan 3, 2018

Test failure on 32-bit x86 libsemigroups/libsemigroups#60

Closed

steeve mentioned this issue Dec 14, 2018

osx: _FORTIFY_SOURCE=1 is always enabled, which breaks asan bazelbuild/bazel#6932

Closed

thibault-martinez mentioned this issue Dec 26, 2018

infra: fix macOS *san builds iotaledger/entangled#642

Merged

matzbot pushed a commit to ruby/ruby that referenced this issue May 23, 2019

disable _FORTIFY_SOURCE

8fce833

Sanitizers and fortifications do not interface, and there is currently no plan for them to work together. See also google/sanitizers#247

ramosian-glider unassigned google Oct 14, 2019

jesec added a commit to jesec/rtorrent that referenced this issue Jan 16, 2021

bazel: set D_FORTIFY_SOURCE to 0 when asan is enabled

60be0d4

Bug: bazelbuild/bazel#6932, google/sanitizers#247

Crypt-iQ mentioned this issue Apr 4, 2022

configure.ac: disable FORTIFY_SOURCE for asan/msan/tsan bitcoin/bitcoin#24763

Closed

ktmf01 mentioned this issue Jun 22, 2022

MSAN issue disappearing when adding -O0 google/oss-fuzz#7898

Closed

lzaoral added a commit to lzaoral/csmock that referenced this issue Jan 30, 2023

gcc: disable code fortification with sanitizers

61bbea4

Related: google/sanitizers#247 (comment)

lzaoral added a commit to lzaoral/csmock that referenced this issue Feb 1, 2023

gcc: disable code fortification with sanitizers

903bf79

Related: google/sanitizers#247 (comment)

MaskRay mentioned this issue Feb 4, 2023

Sanitizer test regressions (mostly ASAN) llvm/llvm-project#60394

Closed

lzaoral added a commit to lzaoral/csmock that referenced this issue Feb 6, 2023

gcc: disable code fortification with sanitizers

19b9432

Related: google/sanitizers#247 (comment)

lzaoral added a commit to lzaoral/csmock that referenced this issue Feb 6, 2023

gcc: disable code fortification with sanitizers

eec74d5

Related: google/sanitizers#247 (comment)

lzaoral added a commit to lzaoral/csmock that referenced this issue Feb 15, 2023

gcc: disable code fortification with sanitizers

f7ef638

Related: google/sanitizers#247 (comment)

sharadhr mentioned this issue Sep 7, 2023

Add sanitizer option to user presets friendlyanon/cmake-init#81

Open

lzaoral mentioned this issue Nov 16, 2023

gcc: properly disable annobin for RPM packages csutils/csmock#139

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support source fortification #247

Support source fortification #247

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

kcc commented Dec 1, 2015

ghost commented Dec 3, 2015

kcc commented Dec 3, 2015

kcc commented Aug 24, 2016

sitsofe commented Aug 25, 2016

kcc commented Aug 25, 2016

westurner commented Dec 6, 2019 •

edited

westurner commented Dec 6, 2019 •

edited

yugr commented Dec 6, 2019 •

edited

jiridanek commented Oct 19, 2022

Support source fortification #247

Support source fortification #247

Comments

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

kcc commented Dec 1, 2015

ghost commented Dec 3, 2015

kcc commented Dec 3, 2015

kcc commented Aug 24, 2016

sitsofe commented Aug 25, 2016

kcc commented Aug 25, 2016

westurner commented Dec 6, 2019 • edited

westurner commented Dec 6, 2019 • edited

yugr commented Dec 6, 2019 • edited

jiridanek commented Oct 19, 2022

westurner commented Dec 6, 2019 •

edited

westurner commented Dec 6, 2019 •

edited

yugr commented Dec 6, 2019 •

edited