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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202004231224.D6B3B650@keescook>
Date:   Thu, 23 Apr 2020 12:32:32 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>
Subject: Re: linux-next: Tree for Apr 22 (objtool warnings)

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