linux-kernel - Re: [PATCH] Kconfig: Explicitly disable asm goto w/ outputs on gcc-11 (and earlier)

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: <CAHk-=whGn5j-1whM66VWJ=tVmpMFO8Q91uuFAJUXa5hG-PWdxA@mail.gmail.com>
Date: Fri, 9 Feb 2024 10:56:10 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: "Andrew Pinski (QUIC)" <quic_apinski@...cinc.com>, Nick Desaulniers <ndesaulniers@...gle.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Masahiro Yamada <masahiroy@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH] Kconfig: Explicitly disable asm goto w/ outputs on gcc-11
 (and earlier)

On Fri, 9 Feb 2024 at 10:43, Sean Christopherson <seanjc@...gle.com> wrote:
>
> > We've removed that workaround in commit 43c249ea0b1e ("compiler-gcc.h:
> > remove ancient workaround for gcc PR 58670"), I'm wondering if maybe
> > that removal was a bit optimistic.
>
> FWIW, reverting that does restore correct behavior on gcc-11.

Hmm. I suspect we'll just have to revert that commit then - although
probably in some form where it only affects the "this has outputs"
case.

Which is much less common than the non-output "asm goto" case.

It does cause gcc to generate fairly horrific code (as noted in the
commit), but it's almost certainly still better code than what the
non-asm-goto case results in.

We have very few uses of CC_HAS_ASM_GOTO_OUTPUT (and the related
CC_HAS_ASM_GOTO_TIED_OUTPUT), but unsafe_get_user() in particular
generates horrid code without it.

But it would be really good to understand *what* that secondary bug
is, and the fix for it. Just to make sure that gcc is really fixed,
and there isn't some pending bug that we just keep hiding with that
extra empty volatile asm.

Andrew?

                   Linus