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-=wha6sXik-f0RC91TMbt4snau0jK+dPvQEMezGiVFDpKUQ@mail.gmail.com>
Date: Sun, 20 Jul 2025 11:35:00 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Gleixner <tglx@...utronix.de>, Ard Biesheuvel <ardb@...nel.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [GIT pull] x86/urgent for v6.16-rc7

On Sun, 20 Jul 2025 at 05:05, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> A single fix for a GCC wreckage, which emits a KCSAN instrumentation call
> in __sev_es_nmi_complete() despite the function being annotated with
> 'noinstr'. As all functions in that source file are noinstr, exclude the
> whole file from KCSAN in the Makefile to cure it.

Hmm. I'm not entirely sure if this counts as a gcc bug.

In particular, look at the *declaration* of __sev_es_nmi_complete() in
<asm/sev.h>, and note the complete lack of 'noinstr':

    extern void __sev_es_nmi_complete(void);

and I wonder if it might be the case that gcc might pick up the lack
of 'noinstr' from the declaration, even if it's there in the
definition..

The fix for this obviously ends up working and is fine regardless, but
it's _possible_ that this is self-inflicted pain rather than an
outright compiler bug. Because having a declaration and a definition
that doesn't match sounds like a bad idea in the first place.

               Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ