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

Message-ID: <CAMj1kXHiA91hH80tHFCO9QjkkfzEGZ2GJgpHnuKrusKhOULMXA@mail.gmail.com>
Date: Mon, 17 Nov 2025 12:51:49 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Brendan Jackman <jackmanb@...gle.com>
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: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