Re: [PATCH v2] x86/kexec: Disable KCOV instrumentation after load_segments()

[Aleksandr Nogikh]

On Sun, Mar 22, 2026 at 1:08 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, 17 Mar 2026 23:03:19 +0100 Aleksandr Nogikh <nogikh@xxxxxxxxxx> wrote:
>
> > The load_segments() function changes segment registers, invalidating
> > GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is
> > enabled, any subsequent instrumented C code call (e.g.
> > native_gdt_invalidate()) begins crashing the kernel in an endless
> > loop.
> >
> > ...
> >
> > Disabling instrumentation for the individual functions would be too
> > fragile, so let's fix the bug by disabling KCOV instrumentation for
> > the entire machine_kexec_64.c and physaddr.c. If coverage-guided
> > fuzzing ever needs these components in the future, we should consider
> > other approaches.
> >
>
> AI review has questions:
>         https://sashiko.dev/#/patchset/20260317220319.788561-1-nogikh@xxxxxxxxxx

Regarding the comments:

> Does this fix cover the CONFIG_KEXEC_JUMP path where execution returns to a KCOV-instrumented kernel?

It doesn't. The fix only covers the main kexec functionality because
that's where the problem manifested: on syzbot we only use `kexec -p`,
not CONFIG_KEXEC_JUMP.

For CONFIG_KEXEC_JUMP, it should be (hopefully) enough to disable the
KCOV instrumentation for `arch/x86/power/cpu.c`, but I am not sure if
we want to also cover it here.

> Is disabling KCOV for all of physaddr.c an overly broad fix that causes
unnecessary loss of coverage for core memory primitives like __phys_addr()?

Disabling the instrumentation at a more granular level would be more
fragile (this was discussed in the v1 series and mentioned in the v2
commit message). When preparing the patch, I tried annotating
individual functions to resolve the problem, it was quite a
whack-a-mole..

Regarding the __phys_addr coverage: so far, it hasn't been super
important during kernel fuzzing. If necessary, we can easily
reconsider the approach later - for now it's just a few lines in
Makefiles.

-- 
Aleksandr