Re: Making KMSAN compatible with paravirtualization

[Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>]

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