linux-kernel - Re: [GIT pull] objtool/core for v5.16-rc1

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: <YYDwJORywW2FjprP@hirez.programming.kicks-ass.net>
Date:   Tue, 2 Nov 2021 09:00:36 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [GIT pull] objtool/core for v5.16-rc1

On Mon, Nov 01, 2021 at 01:44:39PM -0700, Linus Torvalds wrote:
> On Sun, Oct 31, 2021 at 6:16 PM Thomas Gleixner <tglx@...utronix.de> wrote:
> >
> > please pull the latest objtool/core branch from:
> 
> Hmm. I've pulled this, but I'm not happy about the new warnings it
> generates with an allmodconfig build:

Right, due to fixing the dependency on !PARAVIRT, allyesconfig now does
a noinstr validation, and this is the result.

>   vmlinux.o: warning: objtool: __do_fast_syscall_32()+0xa: call to
> stackleak_track_stack() leaves .noinstr.text section
>    ..
>     mce_setup()+0x18: call to memset ...

Boris was having a poke at the MCE stuff.

>     rcu_dynticks_eqs_enter()+0x0: call to rcu_dynticks_task_trace_enter ...
>     rcu_dynticks_eqs_exit()+0xe: call to rcu_dynticks_task_trace_exit ...
>     rcu_nmi_enter()+0x36: call to __kasan_check_read ...

Fixes for those ^ should be in the rcu tree.

There were also a bunch of Xen ones that should be fixed in the Xen
tree, perhaps you've already pulled that.

>     do_machine_check()+0x27: call to stackleak_track_stack ...
>     do_syscall_64()+0x9: call to stackleak_track_stack ...
>     do_int80_syscall_32()+0x9: call to stackleak_track_stack ...
>     exc_general_protection()+0x22: call to stackleak_track_stack ...
>     fixup_bad_iret()+0x20: call to stackleak_track_stack ...
>     .entry.text+0x10e6: call to stackleak_erase ...
>     .entry.text+0x143: call to stackleak_erase ...
>     .entry.text+0x17d9: call to stackleak_erase ...
> 
> most seem to be about the stackleak thing,

Right, I recently ran into this and hacen't yet had time to look into
it. I suspect my normal build box doesn't have the GCC plugin crud
enabled or somesuch.

I think the GCC stackleak plugin needs fixing, specifically it needs a
function attribute such that it will not emit instrumentation in noinstr
functions. I'll go chase down the developer of that thing.