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()")
?
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