In an effort to enable UBSan on a supported build we will set the following UBSan flags in the Linux ASan opt (and ASan fuzzing) build: bool,bounds,vla-bound These flags were selected because they shouldn't to find too many false positives and the issues they uncover will potentially be security sensitive. The decision to use the existing ASan build vs a new UBSan only build was made (during discussion with decoder) to reduce the number of builds we would need to target when fuzzing. I am not against the idea of a standalone UBSan build this just seems to be the best way forward at the moment.

Fixes jit6 test failure

Update string line breaks

Comment on attachment 8988290 [details] [diff] [review] wip.diff Review of attachment 8988290 [details] [diff] [review]: ----------------------------------------------------------------- ::: build/unix/mozconfig.asan @@ +14,5 @@ > fi > > +export SANFLAGS="bool,bounds,vla-bound" > +export CFLAGS="$CFLAGS -fsanitize=$SANFLAGS -fno-sanitize-recover=$SANFLAGS" > +export CXXFLAGS="$CXXFLAGS -fsanitize=$SANFLAGS -fno-sanitize-recover=$SANFLAGS" Note: I had to modify build/autoconf/sanitize.m4 the same way to get ubsan on in SpiderMonkey shell compiled the same way without mach.

We are planning to expose the supported UBSan flags via a build flag. For example --enable-supported-ubsan (name still undecided, suggestion welcome). This preserves the ability to create an ASan build without UBSan if desired. This flag should be used with regular ASan (opt and debug) as well as ASan fuzzing builds. This flag will be useful in cases such as the ASan nightly project where it will not be used by default but will allow us to test performance and stability before enabling it. Additional UBSan flags will be added in the future. Nathan, do you have any suggestions or objections? Where should the UBSan flag config live? ATM it has been temporarily placed in mozconfig.asan which should change.

You want to add a new option such for enabling certain ubsan checks such that it can be combined with --enable-asan? Is the option useful on its own? Maybe instead you should have --enable-asan=(none | standalone | with-ubsan-checks) (names subject to bikeshedding) instead?

I think it'd be useful for ASAN and UBSAN be set independently, so that you could just enable either (or both). And, as suggested in the merged bug, the flag optionally taking a list of checks. --enable-undefined-sanitizer=bool,array-bounds,float-divide-by-zero

(In reply to pdknsk from comment #8) > I think it'd be useful for ASAN and UBSAN be set independently, so that you > could just enable either (or both). Having independent ASan and UBSan builds increase the number of builds that need to be maintained, tested and fuzzed. Though I'm not against the idea I think a good starting point is ASan with some optional UBSan for now (making the current Linux ASan builds ASan+UBSan). FWIW I have a bunch of open UBSan bugs that are not getting much attention. The reason we have chosen the UBSan flags we have is to focus on bugs that have the most potential security impact and are the least likely to be ignored.

Ah, I think the other bug may not be a complete duplicate then. I didn't mean that there should be builds for both, just that the flags should be allowed to be set independently. (So that you can make builds with either or both yourself.)