[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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>




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.