Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Arvind Sankar <nivedita@alum.mit.edu>
Date:   Thu, 14 May 2020 01:22:34 -0400
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Andy Lutomirski <luto@amacapital.net>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Borislav Petkov <bp@suse.de>, Arnd Bergmann <arnd@arndb.de>,
        Arvind Sankar <nivedita@alum.mit.edu>,
        Kalle Valo <kvalo@codeaurora.org>,
        linux-wireless <linux-wireless@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: gcc-10: kernel stack is corrupted and fails to boot
Message-ID: <20200514052234.GA1894416@rani.riverdale.lan>
References: <20200513214128.GB6733@zn.tnic>
 <CAK8P3a3XPCyNM7s3vbn8JYK6swA3ZpPtTWB+uhmAE3YEX-nmig@mail.gmail.com>
 <20200513222038.GC6733@zn.tnic>
 <CAHk-=wgybuOF+Jp2XYWqM7Xn1CW6szWQw_FgVoFh5jx_4YoCVw@mail.gmail.com>
 <20200513233616.GD6733@zn.tnic>
 <CAHk-=wjZXFe08MiNRevJFGDvX0O6kcQTiK8GFBS7hwUAzB+LQw@mail.gmail.com>
 <CAKwvOd=o_wuiVpw5KVzLEt25W-A9Ah9fzftPZLG+yutqJmWbOg@mail.gmail.com>
 <CAHk-=wg6G+p1RRjR6UZBEuSCDs9=iWBsxrDPTEwqh+y5RayqKA@mail.gmail.com>
 <CALCETrUYA60fWu+=MviKx0NmW+_ppsOcv-ShUXdbyM4EjyfzHQ@mail.gmail.com>
 <CAHk-=wgiGxRgJGS-zyer1C_x2MQUVo6iZn0=aJyuFTqJWk-mpA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHk-=wgiGxRgJGS-zyer1C_x2MQUVo6iZn0=aJyuFTqJWk-mpA@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, May 13, 2020 at 09:52:07PM -0700, Linus Torvalds wrote:
> On Wed, May 13, 2020, 20:50 Andy Lutomirski <luto@amacapital.net> wrote:
> 
> >
> > LTO isn’t a linker taking regular .o files full of regular machine
> > code and optimizing it. That’s nuts.
> >
> 
> Yeah, you're right. I wear originally thinking just an optimizing
> assembler, and then started thinking about link-time optimizations in that
> sense, but it was wrong to then go from that to LTO which has a very
> specific meaning.
> 
> We do have assemblers that do some optimizations, but they tend to all be
> at the single instruction level (eg things like turning "add $128" into
> "sub $-128" which fits in a byte constant).
> 
>     Linus
> 
> >

The gcc docs [1,2] at least don't inspire much confidence that this will
continue working with plain asm("") though:

"Note that GCC’s optimizers can move asm statements relative to other
code, including across jumps."
...
"Note that the compiler can move even volatile asm instructions relative
to other code, including across jump instructions."

Even if we don't include an instruction in it I think it should at least
have a memory clobber, to stop the compiler from deciding that it can be
moved before the call so it can do the tail-call optimization.

[1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
[2] https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile