linux-kernel - Re: [PATCH] x86/sev: Disable GCOV on noinstr object

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] [day] [month] [year] [list]

Message-ID: <CA+i-1C2-DtH326ppTx6V_yJ3HX-H0b5i9GNnXb0Q5mUF-Kexdg@mail.gmail.com>
Date: Mon, 17 Nov 2025 13:37:51 +0100
From: Brendan Jackman <jackmanb@...gle.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>, Bill Wendling <morbo@...gle.com>, 
	Justin Stitt <justinstitt@...gle.com>, linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH] x86/sev: Disable GCOV on noinstr object

On Mon, 17 Nov 2025 at 12:52, Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Mon, 17 Nov 2025 at 12:40, Ard Biesheuvel <ardb@...nel.org> wrote:
> >
> > On Mon, 17 Nov 2025 at 12:11, Brendan Jackman <jackmanb@...gle.com> wrote:
> > >
> > > With Debian clang version 19.1.7 (3+build5) there are calls to
> > > kasan_check_write() from __sev_es_nmi_complete, which violates noinstr.
> > > Fix it by disabling GCOV for the noinstr object, as has been done for
> > > previous such instrumentation issues.
> > >
> > > Signed-off-by: Brendan Jackman <jackmanb@...gle.com>
> > > ---
> > > Details:
> > >
> > >  - ❯❯  clang --version
> > >    Debian clang version 19.1.7 (3+build5)
> > >    Target: x86_64-pc-linux-gnu
> > >    Thread model: posix
> > >    InstalledDir: /usr/lib/llvm-19/bin
> > >
> > >  - Compiling from tip/master at 6f85aad74a70d
> > >
> > >  - Kernel config:
> > >
> > >    https://gist.githubusercontent.com/bjackman/bbfdf4ec2e1dfd0e18657174f0537e2c/raw/a88dcc6567d14c69445e7928a7d5dfc23ca9f619/gistfile0.txt
> > >
> > > Note I also get this error:
> > >
> > > vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x3b: relocation to !ENDBR: machine_kexec_prepare+0x810
> > >
> > > That one's a total mystery to me. I guess it's better to "fix" the SEV
> > > one independently rather than waiting until I know how to fix them both.
> > > ---
> > >  arch/x86/coco/sev/Makefile | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/x86/coco/sev/Makefile b/arch/x86/coco/sev/Makefile
> > > index 3b8ae214a6a64de6bb208eb3b7c8bf12007ccc2c..d2ceae587b6c30b2fb17209a7426e7893dea988c 100644
> > > --- a/arch/x86/coco/sev/Makefile
> > > +++ b/arch/x86/coco/sev/Makefile
> > > @@ -8,3 +8,6 @@ UBSAN_SANITIZE_noinstr.o        := n
> > >  # GCC may fail to respect __no_sanitize_address or __no_kcsan when inlining
> > >  KASAN_SANITIZE_noinstr.o       := n
> > >  KCSAN_SANITIZE_noinstr.o       := n
> > > +
> > > +# Clang 19 and older may fail to respect __no_sanitize_address when inlining
> > > +GCOV_PROFILE_noinstr.o         := n
> > >
> >
> > After Thomas dug into this issue a while ago, I meant to follow up
> > with a fix, or at least something to start the discussion.
> >
> > TL;DR there is nothing wrong with either compiler (as far as this
> > issue is concerned)
> >
> > The issue is that KASAN/KCSAN enabled builds use a version of
> > set_bit() that unconditionally inserts a call to
>
> instrument_atomic_write(), which calls the KASAN/KCSAN intrinsics
> directly, and these are usually only called by compiler generated
> code.
>
> This completely defeats the noinstr per-function annotation, given
> that each compilation unit only incorporates a single version of
> set_bit(), which is the instrumented version unless instrumentation is
> disabled for the entire file.
>
> For the short term, we could avoid this by using arch___set_bit()
> directly in the SEV code that triggers this issue today. But for the
> longer term, we should get write of those explicit calls to
> instrumentation intrinsics, as this is fundamentally incompatible with
> per-function overrides.
>
> https://lore.kernel.org/all/8734aqulch.ffs@tglx/T/#u

Ah, yes thank you I think you are right. My GCOV "fix" seems to be
bogus, it probably just hides the issue with incidental changes.

[Dropping verbose notes so I can remember this next time I come to the
thread...]

I was reading disasm and it appeared that the __sev_es_nmi_complete()
-> kasan_check_write() issue corresponded to the __builtin_memset() in
vc_ghcb_invalidate().

But yeah, why should GCOV cause a kasan_check_write() to be injected,
that doesn't really make sense.

So probably rather than compiler instrumentation of the
__builtin_memset() I am seeing  the __set_bit() in the
ghcb_set_sw_exit_code() that comes right afterwards.