|
[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>
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |