linux-kernel - Re: PANIC: double fault in fixup_bad

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: <20200602175859.GC2604@hirez.programming.kicks-ass.net>
Date:   Tue, 2 Jun 2020 19:58:59 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Marco Elver <elver@...gle.com>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        syzbot <syzbot+dc1fa714cb070b184db5@...kaller.appspotmail.com>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        the arch/x86 maintainers <x86@...nel.org>,
        Oleg Nesterov <oleg@...hat.com>,
        kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: PANIC: double fault in fixup_bad_iret

On Tue, Jun 02, 2020 at 07:51:40PM +0200, Marco Elver wrote:

> We have all attributes except __no_sanitize_coverage. GCC <= 7 has
> problems with __always_inline, so we may just have to bump the
> required compiler or emit a warning.

GCC <= 7 will hard fail the compile with those function attributes.
Bumping the min GCC version for KASAN/UBSAN to avoid that might be best.

> > > Not sure what the best strategy is to minimize patch conflicts. For
> > > now I could send just the patches to add missing definitions. If you'd
> > > like me to send all patches (including modifying 'noinstr'), let me
> > > know.
> >
> > If you're going to do patches anyway, might as well do that :-)
> 
> I was stuck on trying to find ways to emulate __no_sanitize_coverage
> (with no success), and then agonizing which patches to send in which
> sequence. ;-) You made that decision by sending the KCSAN noinstr
> series first, so let me respond to that with what I think we can add
> for KASAN and UBSAN at least.

Excellent, thanks!