On Wed, Oct 26, 2022 at 2:31 AM Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, Oct 26, 2022 at 12:17:55AM +0200, Alexander Potapenko wrote:
> > Make sure usercopy hooks from linux/instrumented.h are invoked for
> > copy_from_user_nmi().
> > This fixes KMSAN false positives reported when dumping opcodes for a
> > stack trace.
> >
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Dave Hansen <dave.hansen@linux.intel.com>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: x86@kernel.org
> > Signed-off-by: Alexander Potapenko <glider@google.com>
> > ---
> >  arch/x86/lib/usercopy.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/x86/lib/usercopy.c b/arch/x86/lib/usercopy.c
> > index f1bb186171562..24b48af274173 100644
> > --- a/arch/x86/lib/usercopy.c
> > +++ b/arch/x86/lib/usercopy.c
> > @@ -6,6 +6,7 @@
> >
> >  #include <linux/uaccess.h>
> >  #include <linux/export.h>
> > +#include <linux/instrumented.h>
> >
> >  #include <asm/tlbflush.h>
> >
> > @@ -44,7 +45,9 @@ copy_from_user_nmi(void *to, const void __user *from,
> unsigned long n)
> >        * called from other contexts.
> >        */
> >       pagefault_disable();
> > +     instrument_copy_from_user_before(to, from, n);
> >       ret = raw_copy_from_user(to, from, n);
> > +     instrument_copy_from_user_after(to, from, n, ret);
> >       pagefault_enable();
> >
> >       return ret;
>
> Is all that instrumentation NMI safe? ISTR having seen locks in some of
> that *SAN stuff.
>
> Good question.
I think the implicit assumption is that every function in
include/linux/instrumented.h must be NMI-safe (and IRQ safe as well).

For KASAN I believe it to be the case: kasan_check_read() and
kasan_check_write() are pretty simple, and in the worst case we'll get a
spinlock in kasan_report(), which is quite unlikely to be nested (that's a
KASAN bug report interrupted by an NMI, which in turn contains a KASAN bug).
KCSAN also appears to be lockless and may only suffer from the nested bug
report case (still super-rare). Marco, am I correct?

For KMSAN the particular kmsan_unpoison_memory() is just a loop doing a
memset() of several memory regions belonging to different pages, it doesn't
even perform reporting.
A bigger issue from the NMI perspective is probably
having __msan_poison_alloca() inserted in every non-noinstr kernel
function, because that hook may acquire the stackdepot lock.

Overall, I think we are safe for now, but I'm a bit afraid this may easily
get out of hand if someone adds more tool hooks to instrumented.h


> Also did this want:
>
> Fixes: 59298997df89 ("x86/uaccess: avoid check_object_size() in
> copy_from_user_nmi()")
>
> ?
>

Ah, this explains why it started popping up.
Yes, the Fixes: tag is relevant here.

-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg