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] [day] [month] [year] [list]

Message-ID: <20200423195116.ftpqx6ff5ydy2jpp@treble>
Date:   Thu, 23 Apr 2020 14:51:16 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Kees Cook <keescook@...omium.org>
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 12:32:32PM -0700, Kees Cook wrote:
> 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).

I think I'm still missing why UBSAN_ALIGNMENT is even possible on x86.
But at least it sounds like your fix will keep the objtool reports from
coming in :-)

-- 
Josh