[PATCH AUTOSEL 6.18] x86/sev: Disable GCOV on noinstr object

[Sasha Levin <sashal@kernel.org>]

From: Brendan Jackman <jackmanb@google.com>

[ Upstream commit 9efb74f84ba82a9de81fc921baf3c5e2decf8256 ]

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
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of Commit: x86/sev: Disable GCOV on noinstr object

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly explains the problem:
- With Clang 19.1.7, GCOV instrumentation causes calls to
  `kasan_check_write()` from `__sev_es_nmi_complete()`
- This violates the `noinstr` (no instrumentation) attribute requirement
- The fix follows an established pattern already used in the same file
  for other sanitizers

Key review tags:
- Signed-off-by maintainers from Google and AMD (Borislav Petkov, well-
  known x86 maintainer)
- Acked-by from Marco Elver (instrumentation/sanitizer expert at Google)

### 2. CODE CHANGE ANALYSIS

The change is trivially simple - one line added to a Makefile:

```makefile
GCOV_PROFILE_noinstr.o          := n
```

This disables GCOV code coverage profiling for the `noinstr.o` object
file. The context shows this follows an established pattern:
- `UBSAN_SANITIZE_noinstr.o := n` - already disables UBSAN
- `KASAN_SANITIZE_noinstr.o := n` - already disables KASAN
- `KCSAN_SANITIZE_noinstr.o := n` - already disables KCSAN

The `noinstr` attribute is critical for code that runs in sensitive
contexts like NMI handlers, where any unexpected function calls can
cause deadlocks, crashes, or undefined behavior.

### 3. CLASSIFICATION

This is a **build fix** that prevents instrumentation violations. When
`noinstr` code gets instrumented:
- NMI handlers may call functions that aren't safe in NMI context
- Potential deadlocks if instrumentation takes locks
- Potential crashes or undefined behavior

This falls squarely under the "build fixes" exception category for
stable backports.

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed**: 2 (including blank line)
- **Files touched**: 1 Makefile only
- **Complexity**: Minimal
- **Risk**: Extremely low

This change cannot cause regressions because:
1. It's a Makefile-only change, not code modification
2. It only disables optional build-time instrumentation
3. GCOV is used for code coverage analysis, not production functionality
4. The pattern is already used in the same file for other sanitizers

### 5. USER IMPACT

- **Affected users**: Those building with GCOV enabled + Clang 19+ + AMD
  SEV support
- **Severity if hit**: noinstr violations in NMI handlers can cause
  crashes or deadlocks - severe
- **Scope**: Relatively niche configuration, but real for users who hit
  it

### 6. STABILITY INDICATORS

- Reviewed and acked by instrumentation expert (Marco Elver)
- Signed off by well-known x86 maintainer (Borislav Petkov)
- Follows well-established pattern in the kernel

### 7. DEPENDENCY CHECK

- No dependencies on other commits
- The affected Makefile with existing `*_SANITIZE_noinstr.o` lines
  exists in stable trees with SEV support

### VERDICT

**Pros:**
- Trivially small change (1 line)
- Fixes a real instrumentation violation issue
- Zero risk of runtime regression
- Follows established pattern already in the file
- Well-reviewed by appropriate experts
- Falls under "build fixes" exception

**Cons:**
- Requires specific toolchain configuration to trigger
- Somewhat niche (Clang 19 + GCOV + SEV)

This is a textbook example of a safe, low-risk build fix. It disables
optional instrumentation for code that must not be instrumented
(`noinstr`). The change is defensive, harmless, and prevents potential
crashes/deadlocks in NMI handlers. Even if users don't actively hit the
issue with their current toolchain, disabling GCOV for noinstr code is
the correct thing to do.

**YES**

 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 3b8ae214a6a64..b2e9ec2f69014 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.51.0