On Tue, Sep 15, 2020 at 02:13:01PM -0700, Nick Desaulniers wrote:
> Triple checking what I wrote above; it looks like the randconfig had
> BOTH CONFIG_KASAN=y and CONFIG_UBSAN=y enabled. Aren't the sanitizers
> supposed to be mutually exclusive? If so, we should ensure that via
> kconfig these can't be selected together via randconfig.
No idea...
> Another peculiarity I noticed was that it seems that enabling
> CONFIG_UBSAN_TRAP=y doesn't allow me to select
> CONFIG_UBSAN_ALIGNMENT=y. Is that intentional? (Looks like it
> lib/Kconfig.ubsan:74).
That was done intentionally by Kees, it was putting traps in a lot of
weird places.
--
Josh
On Tue, 15 Sep 2020 at 23:28, Josh Poimboeuf <[email protected]> wrote:
> On Tue, Sep 15, 2020 at 02:13:01PM -0700, Nick Desaulniers wrote:
> > Triple checking what I wrote above; it looks like the randconfig had
> > BOTH CONFIG_KASAN=y and CONFIG_UBSAN=y enabled. Aren't the sanitizers
> > supposed to be mutually exclusive? If so, we should ensure that via
> > kconfig these can't be selected together via randconfig.
>
> No idea...
They are not mutually exclusive. The big ones like KASAN/KCSAN/KMSAN
are mutually exclusive (compiler complains if you mix the flags), but
UBSAN can be enabled with other sanitizers (and fsanitize-coverage,
although not strictly a "sanitizer" it's still instrumentation based).
In general, we shouldn't artificially disallow mixing them if it's
supported by the compiler and our runtime can handle it.
I'll have a look at the rest tomorrow (UBSAN_TRAP stuff, which
coincidentally also came up in some other patch).
Thanks,
-- Marco