On 11/11/2022 15:21, Vitaly Kuznetsov wrote: > Alexander Potapenko <glider@xxxxxxxxxx> writes: > >> Hi, >> >> While investigating KMSAN's incompatibilities with the default Ubuntu >> config (https://github.com/google/kmsan/issues/89#issuecomment-1310702949), >> I figured out that a kernel won't boot with both CONFIG_KMSAN=y and >> CONFIG_XEN_PV=y. >> >> In particular, it may crash in load_percpu_segment(): >> >> __loadsegment_simple(gs, 0); >> wrmsrl(MSR_GS_BASE, cpu_kernelmode_gs_base(cpu)); >> >> Here the value of %gs between __loadsegment_simple() and wrmsrl() is >> zero, so when KMSAN's __msan_get_context_state() instrumentation >> function is called before the actual WRMSR instruction is performed, >> it will attempt to access percpu data and crash. >> >> Unless instructed otherwise (by noinstr or __no_sanitize_memory on the >> source level, or by KMSAN_SANITIZE := n on the Makefile level), KMSAN >> inserts instrumentation at function prologue for every non-inlined >> function, including native_write_msr(). >> >> Marking native_write_msr() noinstr actually makes the kernel boot for >> me, but I am not sure if this is enough. In fact we'll need to fix >> every situation in which instrumentation code may be called with >> invalid %gs value. Do you think this is feasible? Overall, should we >> care about KMSAN working with paravirtualization? > I think XEN PV is really special, let's Cc: xen-devel@ first. Xen PV has some some quirks, but it's really not as special as most people think. Certainly not relevant here. It's actually load_percpu_segment() which is broken here, and was fixed in the call depth tracking series. https://lore.kernel.org/lkml/166601847113.401.13616810593513367893.tip-bot2@tip-bot2/ ~Andrew
