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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200425221728.GE24294@zn.tnic>
Date:   Sun, 26 Apr 2020 00:17:28 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Segher Boessenkool <segher@...nel.crashing.org>
Cc:     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:
> 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.

Well, there is only one reason *why* so far - to prevent the stack
canary cookie from being checked before returning from the function
which set it. That could be explained once over the macro definition so
that it can be looked up.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette