Re: linux-next: Tree for Apr 22 (objtool warnings)

[Kees Cook <keescook@chromium.org>]

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