linux-kernel - Re: [PATCH] x86: Fix early boot crash on gcc-10, next try

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200425222504.GA1080319@rani.riverdale.lan>
Date:   Sat, 25 Apr 2020 18:25:04 -0400
From:   Arvind Sankar <nivedita@...m.mit.edu>
To:     Segher Boessenkool <segher@...nel.crashing.org>
Cc:     Borislav Petkov <bp@...en8.de>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        Jakub Jelinek <jakub@...hat.com>, jgross@...e.com,
        x86@...nel.org, Kees Cook <keescook@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        linuxppc-dev@...ts.ozlabs.org, Michael Matz <matz@...e.de>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Sergei Trofimovich <slyfox@...too.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Ingo Molnar <mingo@...hat.com>,
        Paul Mackerras <paulus@...ba.org>,
        Andy Lutomirski <luto@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Frédéric Pierret (fepitre) 
        <frederic.pierret@...es-os.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Martin Liška <mliska@...e.cz>,
        boris.ostrovsky@...cle.com
Subject: Re: [PATCH] x86: Fix early boot crash on gcc-10, next try

On Sat, Apr 25, 2020 at 02:15:49PM -0500, Segher Boessenkool wrote:
> On Sat, Apr 25, 2020 at 08:53:13PM +0200, Borislav Petkov wrote:
> > On Sat, Apr 25, 2020 at 01:37:01PM -0500, Segher Boessenkool wrote:
> > > That is a lot more typing then
> > > 	asm("");
> > 
> > That's why a macro with a hopefully more descriptive name would be
> > telling more than a mere asm("").
> 
> My point is that you should explain at *every use* of this why you cannot
> have tail calls *there*.  This is very unusual, after all.
> 
> There are *very* few places where you want to prevent tail calls, that's
> why there is no attribute for it.
> 
> 
> Segher

Well, there is -fno-optimize-sibling-calls, but we wouldn't be able to
use it via the optimize attribute for the same reason we couldn't use
no-stack-protector.