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]

Date:   Thu, 23 Apr 2020 13:28:45 -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>
Subject: Re: linux-next: Tree for Apr 22 (objtool warnings)

On Thu, Apr 23, 2020 at 11:06:14AM -0700, Kees Cook wrote:
> On Wed, Apr 22, 2020 at 11:44:06AM -0500, Josh Poimboeuf wrote:
> > On Wed, Apr 22, 2020 at 08:35:29AM -0700, Randy Dunlap wrote:
> > > On 4/22/20 12:10 AM, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > Changes since 20200421:
> > > > 
> > > 
> > > on x86_64:
> > 
> > In both cases the unreachable instruction happens immediately after a
> > call to a function which is truncated with a UD2 (because of
> > UBSAN_TRAP).
> > 
> > When I remove UBSAN_TRAP, the UD2s are replaced with calls to
> > __ubsan_handle_type_mismatch_v1().
> 
> Hrm, these are coming out of CONFIG_UBSAN_MISC, yes? It seems that the
> UBSAN checks that are non-recoverable all inject unreachable checks
> afterwards, from what I can see.
> 
> > Kees, any idea?
> 
> Isn't this another version of the earlier unreachable-ud2 issue?

Yes, basically.  Objtool has figured out that these are calls to
functions which never return.  So the instruction after the call is
unreachable.  Usually GCC also knows that, and knows not to emit the
extra unusuable instructions, but I guess this plugin is different.

> 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?

-- 
Josh