RFR(S): 8252407: Build failure with gcc-8+ and asan

Kim Barrett kim.barrett at oracle.com
Wed Sep 30 10:23:50 UTC 2020


> On Sep 30, 2020, at 3:30 AM, Eric Liu <eric.c.liu at arm.com> wrote:
> 
> Hi Kim,
> 
> Thanks for your review.
> I tried to solve the problem with your suggestion, and have just one question.
> 
>> On 29 September 2020 18:51 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> With gcc10.2, and using the --enable-asan configure option, we get a
>> -Wstringop-truncation warning in CompilerCounters::set_current_method, even
>> after careful adjustment of the code to use the documented idiom for
>> avoiding that warning.
>> 
>> I initially wondered whether this might be only in fastdebug builds, where
>> we also define _FORTIFY_SOURCE=2.  The asan faq
>> https://urldefense.com/v3/__https://github.com/google/sanitizers/wiki/AddressSanitizer*faq__;Iw!!GqivPVa7Brio!IFzpRJ6UwKlp2que6K1FLh9xe_Oe3s-shyGmlz3pzFTlEyZwdqk7yjfH_uovCn8U$ 
>> says asan doesn't work well with _FORTIFY_SOURCE.
>> 
>> But the same warning occurs in a release build, where we aren't defining
>> _FORTIFY_SOURCE.
> 
>> At this point all I can conclude is that --enable-asan (i.e.
>> -fsanitize=address) is simply incompatible with -Wstringop-truncation, at
>> least through gcc10.  That seems like a bug that someone should report.
>> (Might be same as or related to https://urldefense.com/v3/__https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650__;!!GqivPVa7Brio!IFzpRJ6UwKlp2que6K1FLh9xe_Oe3s-shyGmlz3pzFTlEyZwdqk7yjfH_sMh77QA$ )
>> 
>> We don't normally build with -fsanitize=address; that's something that
>> someone might want to turn on sometimes for testing or debugging, but I
>> don't think we're planning to have it always on, even in debug builds.
> 
>> Since it seems to be incompatible with various other options that we *do*
>> normally use, I think the way to allow --enable-asan to be (possibly) usable
>> is in the build system at configure time. That is, the --enable-asan
>> configure option should, in addition to adding -fsanitize=address, also (1)
>> disable -Wstringop-truncation and (2) disable the defining of
>> _FORTIFY_SOURCE in fastdebug builds.  It looks like making those changes
>> involves conditionalizing their addition/removal using ${ASAN_ENABLED}.
> 
> Disable -Wstringop-truncation seems more reasonable. 
> Is that necessary to disable _FORTIFY_SOURCE in fastdebug? With gcc10.1, 
> disable -Wstringop-truncation seems enough. 
> 
> I didn't test with fastdebug mode before, and now it has been tested in our internal
> both with release and fastdebug mode.

My suggestiion that _FORTIFY_SOURCE should be disabled too is based on what the
ASan FAQ and various bug reports and related threads say, which seems to be that
combining ASan and _FORTIFY_SOURCE can cause problems to be missed and can
lead to very strange fortify warnings.

I found a couple of threads from a few years ago suggesting that maybe ASan should have
interceptors for the fortify functions, but didn’t find any indication that’s actually happened.
If it has, then the combination is presumably no longer problematic.





More information about the security-dev mailing list