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. -- Vitaly
