On Thu, Apr 23, 2020 at 01:28:45PM -0500, Josh Poimboeuf wrote: > On Thu, Apr 23, 2020 at 11:06:14AM -0700, Kees Cook wrote: > > Regardless, the type_mismatch it triggered for misalignment and > > object-size checks, and the alignment check is likely going to always > > misfire on x86. The randconfig includes that config: > > > > CONFIG_UBSAN_ALIGNMENT=y > > > > So perhaps the config should be strengthened to disallow it under > > COMPILE_TEST? > > > > config UBSAN_ALIGNMENT > > def_bool !UBSAN_NO_ALIGNMENT > > depends on !COMPILE_TEST > > But this issue basically makes UBSAN_TRAP unusable, right? Should > UBSAN_ALIGNMENT and UBSAN_TRAP be made mutually exclusive? Well, no, not UBSAN_TRAP alone. It seems that -fsanitize=alignment (and possibly -fsanitize=object-size) is likely to produce false positives. And that was already well understood. With UBSAN_TRAP, though, those functions become unusable. Part of the goal of adding UBSAN_TRAP was to be able to extract the non-false-positive sanitizer options out of UBSAN_MISC so they could be used in production without the large debug text overhead. (And the "alignment" checker had long since already been separate and set to false by default on x86, since it's going to trip over everything since it shouldn't get run on such hardware for any sane reason that I know of.) So, while UBSAN_TRAP with UBSAN_ALIGNMENT is going to be especially bad, UBSAN_ALIGNMENT at all is likely bad enough on x86, so I think it'd be best to make it a negative depends on COMPILE_TEST (but leave it available if someone is doing some really unusual UBSAN work). -Kees -- Kees Cook
