[PATCH RFC] x86/xen/pvh: Disable KASAN in early pvh boot stages

From: Guillaume Ranquet

Date: Tue Jun 23 2026 - 09:37:37 EST


Running a xen pvh guest under KASAN results in a triple fault as the
KASAN shadow region is not initialized this early in the boot flow.

(XEN) [ 2.018691] d0v0 Triple fault - invoking HVM shutdown action 1
(XEN) [ 2.018693] *** Dumping Dom0 vcpu#0 state: ***
(XEN) [ 2.018695] ----[ Xen-4.20.1-pre x86_64 debug=n Not tainted ]----
(XEN) [ 2.018697] CPU: 0
(XEN) [ 2.018698] RIP: 0008:[<ffffffff842be38b>]
(XEN) [ 2.018698] RFLAGS: 0000000000000006 CONTEXT: hvm guest (d0v0)
(XEN) [ 2.018700] rax: dffffc00072775d7 rbx: 00000000072775d7 rcx: 0000000000000000
(XEN) [ 2.018702] rdx: ffffffff843b56c0 rsi: 00000000336ec578 rdi: ffffffff8368c1ec
(XEN) [ 2.018703] rbp: 00000000393baff0 rsp: 00000000393baeb8 r8: 00000000393bb000
(XEN) [ 2.018704] r9: 00000000393bb00c r10: 0000000000000000 r11: 0000000000000000
(XEN) [ 2.018706] r12: ffffffff843b56c0 r13: 00000000393bb008 r14: 00000000393bb000
(XEN) [ 2.018707] r15: 0000000040000000 cr0: 0000000080000011 cr4: 0000000000000020
(XEN) [ 2.018708] cr3: 00000000393bc000 cr2: 0000000000000000
(XEN) [ 2.018709] fsb: 0000000000000000 gsb: 00000000393b7020 gss: 0000000000000000
(XEN) [ 2.018711] ds: 0010 es: 0010 fs: 0000 gs: 0000 ss: 0010 cs: 0008
(XEN) [ 2.018712] Hardware Dom0 shutdown: rebooting machine
(XEN) [ 2.180946] Resetting with ACPI MEMORY or I/O RESET_REG.

Signed-off-by: Guillaume Ranquet <granquet@xxxxxxxxxxxxxx>
---
The KASAN shadow region is not initialized this early in the boot stage,
so disable instrumentation of the early boot.

Though I'm wondering if disabling KASAN for `arch/x86/kernel/cpu/common.c` is the right move.
There's a single call to `get_cpu_vendor()` from `arch/x86/xen/enlighten.c`.

I haven't looked if there's a solution to avoid disabling KASAN for
everyone in `common.c`.

Opinions welcome?

Also note that I haven't tested HVM/PV or PVHVM.
---
arch/x86/kernel/cpu/Makefile | 2 ++
arch/x86/xen/Makefile | 4 ++++
drivers/xen/Makefile | 2 ++
3 files changed, 8 insertions(+)

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index d2e8a849f180..8d1d45c231bc 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -17,6 +17,8 @@ KMSAN_SANITIZE_common.o := n
# As above, instrumenting secondary CPU boot code causes boot hangs.
KCSAN_SANITIZE_common.o := n

+KASAN_SANITIZE_common.o := n
+
obj-y := cacheinfo.o scattered.o
obj-y += topology_common.o topology_ext.o topology_amd.o
obj-y += cpuid_parser.o
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 717264ae269b..940284eb9835 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -7,6 +7,10 @@ CFLAGS_REMOVE_time.o = -pg
CFLAGS_REMOVE_irq.o = -pg
endif

+KASAN_SANITIZE_enlighten_pvh.o := n
+KASAN_SANITIZE_enlighten.o := n
+KASAN_SANITIZE_efi.o := n
+
# Make sure early boot has no stackprotector
CFLAGS_enlighten_pv.o := -fno-stack-protector
CFLAGS_mmu_pv.o := -fno-stack-protector
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index c0503f1c7d5b..d71742c382dd 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -5,6 +5,8 @@ obj-y += mem-reservation.o
obj-y += events/
obj-y += xenbus/

+KASAN_SANITIZE_efi.o := n
+
CFLAGS_features.o := -fno-stack-protector

dom0-$(CONFIG_ARM64) += arm-device.o

---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260623-xen_kasan-5571a38f2b5e

Best regards,
--
Guillaume Ranquet <granquet@xxxxxxxxxxxxxx>