[PATCH v3 0/3] Noinstr fixes for K[CA]SAN with GCOV

[PATCH v3 0/3] Noinstr fixes for K[CA]SAN with GCOV

[Brendan Jackman]

As discussed in [2], the GCOV+*SAN issue is attacked from two angles:
both adding __always_inline to the instrumentation helpers AND disabling
GCOV for noinstr.c. Only one or the other of these things is needed to
make the build error go away, but they both make sense in their own
right and both may serve to prevent other similar errors from cropping
up in future.

Note I have not annotated !CONFIG_* stubs, only !__SANITIZE_*__ ones.
That's because for global settings (i.e. kconfig) it remains a bug to
call these stubs from the wrong context and we'd probably like to detect
that bug even if it could be eliminated from the current build. 

Concretely, the above is talking about KMSAN, i.e. stuff like
instrument_copy_from_user().

Other than that, I think everything in include/linux/instrumented.h is
covered now.

Signed-off-by: Brendan Jackman <jackmanb@google.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

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

Note I also mentioned other similar errors in [0]. Those errors don't
exist in Linus' master and I didn't note down where I saw them. Either
they have since been fixed, or I observed them in Google's internal
codebase where they were instroduced downstream.

Changes in v3:
- Also fix __kcsan_{dis,en}able_current()
- Link to v2: https://lore.kernel.org/r/20251215-gcov-inline-noinstr-v2-0-6f100b94fa99@google.com

Changes in v2:
- Also disable GCOV for noinstr.c (i.e. squash in [0]).
- Link to v1: [2] 

[0] https://lore.kernel.org/all/DERNCQGNRITE.139O331ACPKZ9@google.com/
[1] https://lore.kernel.org/all/20251117-b4-sev-gcov-objtool-v1-1-54f7790d54df@google.com/
[2] https://lore.kernel.org/r/20251208-gcov-inline-noinstr-v1-0-623c48ca5714@google.com

---
Brendan Jackman (3):
      kasan: mark !__SANITIZE_ADDRESS__ stubs __always_inline
      kcsan: mark !__SANITIZE_THREAD__ stubs __always_inline
      x86/sev: Disable GCOV on noinstr object

 arch/x86/coco/sev/Makefile   | 2 ++
 include/linux/kasan-checks.h | 4 ++--
 include/linux/kcsan-checks.h | 8 ++++----
 3 files changed, 8 insertions(+), 6 deletions(-)
---
base-commit: 40fbbd64bba6c6e7a72885d2f59b6a3be9991eeb
change-id: 20251208-gcov-inline-noinstr-1550cfee445c

Best regards,
-- 
Brendan Jackman <jackmanb@google.com>

[PATCH v3 1/3] kasan: mark !__SANITIZE_ADDRESS__ stubs __always_inline

[Brendan Jackman]

The x86 instrumented bitops in
include/asm-generic/bitops/instrumented-non-atomic.h are
KASAN-instrumented via explicit calls to instrument_* functions from
include/linux/instrumented.h.

This bitops are used from noinstr code in __sev_es_nmi_complete(). This
code avoids noinstr violations by disabling __SANITIZE_ADDRESS__ etc for
the compilation unit.

However, when GCOV is enabled, there can still be violations caused by
the stub versions of these functions, since coverage instrumentation is
injected that causes them to be out-of-lined.

Fix this by just applying __always_inline.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 include/linux/kasan-checks.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/kasan-checks.h b/include/linux/kasan-checks.h
index 3d6d22a25bdc391c0015a6daf2249d6bea752dcb..9aa0f1cc90133ca334afa478b5f762aef9e5d79c 100644
--- a/include/linux/kasan-checks.h
+++ b/include/linux/kasan-checks.h
@@ -37,11 +37,11 @@ static inline bool __kasan_check_write(const volatile void *p, unsigned int size
 #define kasan_check_read __kasan_check_read
 #define kasan_check_write __kasan_check_write
 #else
-static inline bool kasan_check_read(const volatile void *p, unsigned int size)
+static __always_inline bool kasan_check_read(const volatile void *p, unsigned int size)
 {
 	return true;
 }
-static inline bool kasan_check_write(const volatile void *p, unsigned int size)
+static __always_inline bool kasan_check_write(const volatile void *p, unsigned int size)
 {
 	return true;
 }

-- 
2.50.1

Re: [PATCH v3 1/3] kasan: mark !__SANITIZE_ADDRESS__ stubs __always_inline

[Peter Zijlstra]

On Tue, Dec 16, 2025 at 10:16:34AM +0000, Brendan Jackman wrote:
> The x86 instrumented bitops in
> include/asm-generic/bitops/instrumented-non-atomic.h are
> KASAN-instrumented via explicit calls to instrument_* functions from
> include/linux/instrumented.h.
> 
> This bitops are used from noinstr code in __sev_es_nmi_complete(). This
> code avoids noinstr violations by disabling __SANITIZE_ADDRESS__ etc for
> the compilation unit.

Yeah, so don't do that? That's why we use raw_atomic_*() in things like
smp_text_poke_int3_handler().

Re: [PATCH v3 1/3] kasan: mark !__SANITIZE_ADDRESS__ stubs __always_inline

[Brendan Jackman]

On Tue Dec 16, 2025 at 1:01 PM UTC, Peter Zijlstra wrote:
> On Tue, Dec 16, 2025 at 10:16:34AM +0000, Brendan Jackman wrote:
>> The x86 instrumented bitops in
>> include/asm-generic/bitops/instrumented-non-atomic.h are
>> KASAN-instrumented via explicit calls to instrument_* functions from
>> include/linux/instrumented.h.
>> 
>> This bitops are used from noinstr code in __sev_es_nmi_complete(). This
>> code avoids noinstr violations by disabling __SANITIZE_ADDRESS__ etc for
>> the compilation unit.
>
> Yeah, so don't do that? That's why we use raw_atomic_*() in things like
> smp_text_poke_int3_handler().

Right, this was what Ard suggested in [0]:

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

But, I think the longer term solution is actually now coming from what
Marco described in [1].

So in the meantime what's the cleanest fix? Going straight to the arch_*
calls from SEV seems pretty yucky in its own right. Adding special
un-instrumented wrappers in bitops.h seems overblown for a temporary
workaround. Meanwhile, disabling __SANITIZE_ADDRESS__ is something the
SEV code already relies on as a workaround, so if we can just make that
workaround work for this case too, it seems like a reasonable way
forward?

Anyway, I don't feel too strongly about this, I'm only pushing back
for the sake of hysteresis since I already flipflopped a couple of times
on this fix. If Ard/Marco agree with just using the arch_ functions
directly I'd be fine with that.

And in the meantime, I guess patch 3/3 is OK? As it happens, that will
already make the current error go away without needing the first 2
patches. So maybe we should just merge that and be done with it? There's
probably a good chance no other issues will show up between now and
whenever Marco's nice compiler support arrives.

[0] https://lore.kernel.org/all/CAMj1kXHiA91hH80tHFCO9QjkkfzEGZ2GJgpHnuKrusKhOULMXA@mail.gmail.com/
[1] https://lore.kernel.org/all/CANpmjNNc9vRJbD2e5DPPR8SWNSYa=MqTzniARp4UWKBUEdhh_Q@mail.gmail.com/

Re: [PATCH v3 1/3] kasan: mark !__SANITIZE_ADDRESS__ stubs __always_inline

[Peter Zijlstra]

On Wed, Dec 17, 2025 at 01:53:33PM +0000, Brendan Jackman wrote:
> On Tue Dec 16, 2025 at 1:01 PM UTC, Peter Zijlstra wrote:
> > On Tue, Dec 16, 2025 at 10:16:34AM +0000, Brendan Jackman wrote:
> >> The x86 instrumented bitops in
> >> include/asm-generic/bitops/instrumented-non-atomic.h are
> >> KASAN-instrumented via explicit calls to instrument_* functions from
> >> include/linux/instrumented.h.
> >> 
> >> This bitops are used from noinstr code in __sev_es_nmi_complete(). This
> >> code avoids noinstr violations by disabling __SANITIZE_ADDRESS__ etc for
> >> the compilation unit.
> >
> > Yeah, so don't do that? That's why we use raw_atomic_*() in things like
> > smp_text_poke_int3_handler().
> 
> Right, this was what Ard suggested in [0]:
> 
> > For the short term, we could avoid this by using arch___set_bit()

arch_set_bit(), right?

> > 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.
> 
> But, I think the longer term solution is actually now coming from what
> Marco described in [1].

Oh, shiny. But yeah, that is *LONG* term, as in, we can't use that until
this future CLANG (and GCC?) version becomes the minimum version we
support for sanitizer builds.

> So in the meantime what's the cleanest fix? Going straight to the arch_*
> calls from SEV seems pretty yucky in its own right.

This is what I would do (and have done in the past):

 14d3b376b6c3 ("x86/entry, cpumask: Provide non-instrumented variant of cpu_is_offline()")
 f5c54f77b07b ("cpumask: Add a x86-specific cpumask_clear_cpu() helper")

Now, I don't have much to say about SEV; but given Boris did that second
patch above, I'm thinking he won't be objecting too much for doing
something similar in the SEV code.

> Adding special
> un-instrumented wrappers in bitops.h seems overblown for a temporary
> workaround. 

Agreed.

> Meanwhile, disabling __SANITIZE_ADDRESS__ is something the
> SEV code already relies on as a workaround, so if we can just make that
> workaround work for this case too, it seems like a reasonable way
> forward?

I'll defer to Boris on that, this is his code I think.

> Anyway, I don't feel too strongly about this, I'm only pushing back
> for the sake of hysteresis since I already flipflopped a couple of times
> on this fix. If Ard/Marco agree with just using the arch_ functions
> directly I'd be fine with that.

Yeah, fair enough :-)

> And in the meantime, I guess patch 3/3 is OK? 

I'm not sure, ISTR having yelled profanities at GCOV in general for
being just straight up broken. And people seem to insist on adding more
and more *COV variants and I keep yelling at them or something.

That is GCOV, KCOV and llvm-cov are all doing basically the same damn
thing (and sure, llvm-cov gets more edges but details) and we should not
be having 3 different damn interfaces for it. Also, they all should
bloody well respect noinstr and if they don't they're just broken and
all that :-)

That is, I'd as soon just make them all "depend BROKEN" and call it a
day.

Re: [PATCH v3 1/3] kasan: mark !__SANITIZE_ADDRESS__ stubs __always_inline

[Brendan Jackman]

>> 
>> So in the meantime what's the cleanest fix? Going straight to the arch_*
>> calls from SEV seems pretty yucky in its own right.
>
> This is what I would do (and have done in the past):
>
>  14d3b376b6c3 ("x86/entry, cpumask: Provide non-instrumented variant of cpu_is_offline()")
>  f5c54f77b07b ("cpumask: Add a x86-specific cpumask_clear_cpu() helper")

OK, let's do it this way then.


>> > For the short term, we could avoid this by using arch___set_bit()
>
> arch_set_bit(), right?

I don't think so. Currently the GHCB accessors ar using __set_bit() i.e.
the non-atomic version. Am I missing something?

Re: [PATCH v3 1/3] kasan: mark !__SANITIZE_ADDRESS__ stubs __always_inline

[Borislav Petkov]

On Thu, Dec 18, 2025 at 10:24:39AM +0100, Peter Zijlstra wrote:
> > And in the meantime, I guess patch 3/3 is OK? 
> 
> I'm not sure, ISTR having yelled profanities at GCOV in general for
> being just straight up broken. And people seem to insist on adding more
> and more *COV variants and I keep yelling at them or something.
> 
> That is GCOV, KCOV and llvm-cov are all doing basically the same damn
> thing (and sure, llvm-cov gets more edges but details) and we should not
> be having 3 different damn interfaces for it. Also, they all should
> bloody well respect noinstr and if they don't they're just broken and
> all that :-)
> 
> That is, I'd as soon just make them all "depend BROKEN" and call it a
> day.

Right.

And I don't think anyone has had any serious plans for COV-ing the SEV code so
lemme take 3/3.

I, like Peter, am gravitating towards a kill-that-thing-with-a-master-switch
instead of whack-a-mole-ing the kernel.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[PATCH v3 2/3] kcsan: mark !__SANITIZE_THREAD__ stubs __always_inline

[Brendan Jackman]

The x86 instrumented bitops in
include/asm-generic/bitops/instrumented-non-atomic.h are
KCSAN-instrumented via explicit calls to instrument_* functions from
include/linux/instrumented.h.

This bitops are used from noinstr code in __sev_es_nmi_complete(). This
code avoids noinstr violations by disabling __SANITIZE_THREAD__ etc for
the compilation unit.

However, when GCOV is enabled, there can still be violations caused by
the stub versions of these functions, since coverage instrumentation is
injected that causes them to be out-of-lined.

Fix this by just applying __always_inline.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 include/linux/kcsan-checks.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/kcsan-checks.h b/include/linux/kcsan-checks.h
index 92f3843d9ebb8177432bb4eccc151ea66d3dcbb7..c4c8e03e53459f5030ca33f9103a9bde49fd3820 100644
--- a/include/linux/kcsan-checks.h
+++ b/include/linux/kcsan-checks.h
@@ -226,10 +226,10 @@ static inline void kcsan_end_scoped_access(struct kcsan_scoped_access *sa) { }
 #define __kcsan_disable_current kcsan_disable_current
 #define __kcsan_enable_current kcsan_enable_current_nowarn
 #else /* __SANITIZE_THREAD__ */
-static inline void kcsan_check_access(const volatile void *ptr, size_t size,
-				      int type) { }
-static inline void __kcsan_enable_current(void)  { }
-static inline void __kcsan_disable_current(void) { }
+static __always_inline void kcsan_check_access(const volatile void *ptr,
+					       size_t size, int type) { }
+static __always_inline void __kcsan_enable_current(void)  { }
+static __always_inline void __kcsan_disable_current(void) { }
 #endif /* __SANITIZE_THREAD__ */
 
 #if defined(CONFIG_KCSAN_WEAK_MEMORY) && defined(__SANITIZE_THREAD__)

-- 
2.50.1

[PATCH v3 3/3] x86/sev: Disable GCOV on noinstr object

[Brendan Jackman]

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.

Note that this file already disables __SANITIZE_ADDRESS__ and
__SANITIZE_THREAD__, thus calls like kasan_check_write() ought to be
nops regardless of GCOV. This has been fixed in other patches. However,
to avoid any other accidental instrumentation showing up, (and since, in
principle GCOV is instrumentation and hence should be disabled for
noinstr code anyway), disable GCOV overall as well.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 arch/x86/coco/sev/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/coco/sev/Makefile b/arch/x86/coco/sev/Makefile
index 3b8ae214a6a64de6bb208eb3b7c8bf12007ccc2c..b2e9ec2f69014fa3507d40c6c266f1b74d634fcb 100644
--- a/arch/x86/coco/sev/Makefile
+++ b/arch/x86/coco/sev/Makefile
@@ -8,3 +8,5 @@ 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
+
+GCOV_PROFILE_noinstr.o		:= n

-- 
2.50.1

[tip: x86/urgent] x86/sev: Disable GCOV on noinstr object

[tip-bot2 for Brendan Jackman]

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     9efb74f84ba82a9de81fc921baf3c5e2decf8256
Gitweb:        https://git.kernel.org/tip/9efb74f84ba82a9de81fc921baf3c5e2decf8256
Author:        Brendan Jackman <jackmanb@google.com>
AuthorDate:    Tue, 16 Dec 2025 10:16:36 
Committer:     Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Mon, 05 Jan 2026 10:22:48 +01:00

x86/sev: Disable GCOV on noinstr object

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.

Note that this file already disables __SANITIZE_ADDRESS__ and
__SANITIZE_THREAD__, thus calls like kasan_check_write() ought to be nops
regardless of GCOV. This has been fixed in other patches. However, to avoid
any other accidental instrumentation showing up, (and since, in principle GCOV
is instrumentation and hence should be disabled for noinstr code anyway),
disable GCOV overall as well.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Marco Elver <elver@google.com>
Link: https://patch.msgid.link/20251216-gcov-inline-noinstr-v3-3-10244d154451@google.com
---
 arch/x86/coco/sev/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/coco/sev/Makefile b/arch/x86/coco/sev/Makefile
index 3b8ae21..b2e9ec2 100644
--- a/arch/x86/coco/sev/Makefile
+++ b/arch/x86/coco/sev/Makefile
@@ -8,3 +8,5 @@ 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
+
+GCOV_PROFILE_noinstr.o		:= n

Re: [PATCH v3 0/3] Noinstr fixes for K[CA]SAN with GCOV

[Marco Elver]

On Tue, 16 Dec 2025 at 11:16, Brendan Jackman <jackmanb@google.com> wrote:
>
> As discussed in [2], the GCOV+*SAN issue is attacked from two angles:
> both adding __always_inline to the instrumentation helpers AND disabling
> GCOV for noinstr.c. Only one or the other of these things is needed to
> make the build error go away, but they both make sense in their own
> right and both may serve to prevent other similar errors from cropping
> up in future.
>
> Note I have not annotated !CONFIG_* stubs, only !__SANITIZE_*__ ones.
> That's because for global settings (i.e. kconfig) it remains a bug to
> call these stubs from the wrong context and we'd probably like to detect
> that bug even if it could be eliminated from the current build.
>
> Concretely, the above is talking about KMSAN, i.e. stuff like
> instrument_copy_from_user().
>
> Other than that, I think everything in include/linux/instrumented.h is
> covered now.
>
> Signed-off-by: Brendan Jackman <jackmanb@google.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
>
>  - 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.
>
> Note I also mentioned other similar errors in [0]. Those errors don't
> exist in Linus' master and I didn't note down where I saw them. Either
> they have since been fixed, or I observed them in Google's internal
> codebase where they were instroduced downstream.
>
> Changes in v3:
> - Also fix __kcsan_{dis,en}able_current()
> - Link to v2: https://lore.kernel.org/r/20251215-gcov-inline-noinstr-v2-0-6f100b94fa99@google.com

Acked-by: Marco Elver <elver@google.com>

Thanks!