[PATCH 01/11] ubsan: Add initial support for -fsanitize=undefined

[Sam James]

DJ Delorie <dj@redhat.com> writes:

> Most of the rest of the series has comments already, and no longer
> applies cleanly anyway.  Adding my comments below.  Looking forward to
> an updated patch set.
>
> Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
>> It is enabled through a new configure flag, --enable-ubsan, and
>> should be used for debugging and/or testing.  Not all ubsan handlers
>
> Is there any way we could conditionally include the new functions in
> elf/Versions?  Or do the extra functions just get ignored when building
> without this option?  I'm concerned about polluting the published ABI in
> a non-debug build.
>
>> The ubsan handlers are exported from ld.so since they are used on
>> all libraries and tests.  This might interfere with ubsan from
>
> Does this mean that, once this option is enabled, the resulting objects
> should basically *never* be installed?  I wonder if it would be worth
> the effort to disable "make install" (outside of the testroot) when this
> option is enabled.
>
>> There is no support for the UBSAN_OPTIONS environment variable,
>> although some options are supported through glibc.ubsan tunables.
>
> Suggestion: like gcc does, have each handler support off/warning/error
> style selection.  I don't think it would be worth it unless it grows
> beyond the debug stage, though.

Care is required because UBSAN_OPTIONS (as well as the other *_OPTIONS)
can lead to privilege escalation for suid applications with a custom log
file.

Warning is always controversial because the state of the program beyond
that point is unknown, but maybe it is indeed useful especially during
initial testing when we expect to find problems in paths exercised by
applications.

>
>> This preliminary support is still incomplete:
>>
>>   * Not all targets are supported, nor have I checked the test suitei
>>     on all successful targets.  Also, I only checked with limited gcc
>>     versions (only gcc 14.2.1 and for some targets 15.0.0).
>>
>>     Currently --enable-ubsan builds on Linux for aarch64, arm, hppa,
>>     i686, powerpc64, microblaze, mips64, loongarch64, sparc, s390x, and
>>     x86_64.
>>
>>   * The instrumentation is disabled on rltd.c, although it is enabled
>>     on other loaders functions.
>>
>>   * A lot of test cases show failures due to UB.
>>
>> Also, gcc-14 triggers an ICE building math routines.

Is this reported somewhere?

>> gcc-15
>> works correctly.
>
> I wonder if configure needs to check for known supported configurations,
> or if we just document it as "developers only".

I think we should consider it "developers only".
>
>> diff --git a/INSTALL b/INSTALL
>>  
>> +'--enable-ubsan'
>> +     Build the GNU C library with, along with tests, with the
>> +     -fsanitize=undefined compiler option.  The compiler runtime is not
>> +     used, instead UBSAN functions called by the compiler instrumentation
>> +     is provided by glibc itself.
>> +
>> +     This is a debug/development option and the default is to disable
>> +     the instrumentation.
>> +
>
> I'll ask the usual question: what keeps this default-off code from
> bit-rotting over time due to lack of use?

In my experience, UBSAN support is usually sought out by certain people
who will try it every so often (and I'm one of them). I'm not too
worried about it, especially if we can get to the point where the
testsuite is clean, and we can recommend people use it when testing
new patches.

The issue is before we reach that state, but that applies to anything
incremental...

> [...]

sam