osx: _FORTIFY_SOURCE=1 is always enabled, which breaks asan

[steeve]

Description of the problem / feature request:

-D_FORTIFY_SOURCE=1 is enabled by default on OSX. This break when trying to use asan.

$ xcrun --sdk macosx clang -dM -E -fsanitize=address - < /dev/null | grep FORTIFY
#define _FORTIFY_SOURCE 0
$

When running a build with -fsanitize=address, the build outputs warnings with:

<command line>:1:9: warning: '_FORTIFY_SOURCE' macro redefined [-Wmacro-redefined]
#define _FORTIFY_SOURCE 1
        ^
<built-in>:386:9: note: previous definition is here
#define _FORTIFY_SOURCE 0

However, according to https://github.com/google/sanitizers/wiki/AddressSanitizer, _FORTIFY_SOURCE should be disabled when using asan.

A3: If _FORTIFY_SOURCE is enabled, ASan may have false positives, see next question.

Q: I've compiled my code with -D_FORTIFY_SOURCE flag and ASan, or -D_FORTIFY_SOURCE is enabled by default in my distribution (most modern distributions). Now ASan misbehaves (either produces false warnings, or does not find some bugs).

A: Currently ASan (and other sanitizers) doesn't support source fortification, see google/sanitizers#247. The fix should most likely be on the glibc side, see the (stalled) discussion here.

However, adding the following options doesn't help either since it's defined in the CROSSTOOL it seems:

build:asan --copt="-U_FORTIFY_SOURCE"

Feature requests: what underlying problem are you trying to solve with this feature?

Use asan on osx.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Run a C++ build with the following arg:

--copt="-fsanitize=address"

What operating system are you running Bazel on?

osx

What's the output of bazel info release?

release 0.19.0

Have you found anything relevant by searching the web?

1. https://github.com/znly/bazel/blob/master/tools/osx/crosstool/CROSSTOOL.tpl#L64 and throughout the file.
2. Support source fortification google/sanitizers#247

I can submit a PR if everybody approves me of removing it by default.

I'm also noticing it is enabled by default on linux.

We managed to get around using the following configuration:

build:asan              --strip=never
build:asan              --copt="-Wno-macro-redefined"
build:asan              --copt="-D_FORTIFY_SOURCE=0"
build:asan              --copt="-O1"
build:asan              --copt="-fno-omit-frame-pointer"
build:asan              --copt="-fsanitize=address"
build:asan              --copt="-DADDRESS_SANITIZER"
build:asan              --linkopt="-fsanitize=address"

[jgavris]

+1, We're using the following config.

# Address sanitizer config.
# Add --config=asan to your bazel command.
build:asan --strip=never
build:asan --copt -Wno-macro-redefined # Asan sets _FORTIFY_SOURCE=0
build:asan --copt -DADDRESS_SANITIZER
build:asan --copt -D_LIBCPP_HAS_NO_ASAN
build:asan --copt -g
build:asan --copt -fno-omit-frame-pointer
build:asan --copt -fno-optimize-sibling-calls
build:asan --copt -fsanitize=address
build:asan --linkopt -fsanitize=address

[steeve]

@jgavris from what I could read online, you might want to redefine _FORTIFY_SOURCE to 0, see google/sanitizers#247 as to why

[tetromino]

Makes sense. I don't understand why we force _FORTIFY_SOURCE=1 in the public osx CROSSTOOL given that we don't do this in the internal one.

I think we should keep _FORTIFY_SOURCE=1 only in opt mode.

@mhlopko - you have looked at the osx CROSSTOOL before, what do you think?

[steeve]

@tetromino actually I'm guessing the problem also exists on every OS, doesn't it ?

also, what is the status on using sanitizers + blaze inside google ?

[tetromino]

On second thought, I think this is working as intended.

Please try bazel build --features=asan //my:target - that should set a working combination of cflags.

[tetromino]

It seems that --features=asan isn't working for cc_binary on osx, but ideally, that's how we would want to support sanitizers, while still keeping a secure default.

Duplicate of #4984.

[tetromino]

Duplicate of #4984

[keith]

#12772