From: Guillaume Ranquet <ranquet.guillaume@gmail.com>
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Juergen Gross <jgross@suse.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
Guillaume Ranquet <granquet@missingno.tech>
Subject: [PATCH RFC] x86/xen/pvh: Disable KASAN in early pvh boot stages
Date: Tue, 23 Jun 2026 15:37:14 +0200 [thread overview]
Message-ID: <20260623-xen_kasan-v1-1-d963df2233d7@missingno.tech> (raw)
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@missingno.tech>
---
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@missingno.tech>
reply other threads:[~2026-06-23 13:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260623-xen_kasan-v1-1-d963df2233d7@missingno.tech \
--to=ranquet.guillaume@gmail.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=granquet@missingno.tech \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oleksandr_tyshchenko@epam.com \
--cc=sstabellini@kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®