linux-kernel - Re: [GIT pull] x86/urgent for v6.16-rc7

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: <CAMj1kXF_-d4_VVO+RovbXxoK=Gh72yFvHqEdRJ6rQBpSzB+1Gw@mail.gmail.com>
Date: Mon, 21 Jul 2025 13:14:10 +1000
From: Ard Biesheuvel <ardb@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [GIT pull] x86/urgent for v6.16-rc7

On Mon, 21 Jul 2025 at 04:35, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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..
>

Just tried this: adding 'noinstr' to the declaration in asm/sev.h
makes no difference at all.

> 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.
>

Agree with this in principle, and for 'noinstr' in particular, this
may work fine but note that there are __attribute__(()) annotations
that make no sense, or are not permitted on [forward] declarations,
and so having the general rule that declarations and definitions must
have the same annotations may not be feasible in practice.