Messages in this thread | | | From | Alexander Potapenko <> | Date | Mon, 21 Nov 2022 11:28:39 +0100 | Subject | Re: [PATCH] x86: suppress KMSAN reports in arch_within_stack_frames() |
| |
On Mon, Nov 21, 2022 at 11:23 AM Peter Zijlstra <peterz@infradead.org> wrote: > > On Fri, Nov 18, 2022 at 06:23:05PM +0100, Alexander Potapenko wrote: > > arch_within_stack_frames() performs stack walking and may confuse > > KMSAN by stepping on stale shadow values. To prevent false positive > > reports, disable KMSAN checks in this function. > > > > This fixes KMSAN's interoperability with CONFIG_HARDENED_USERCOPY. > > > > Link: https://github.com/google/kmsan/issues/89 > > Link: https://lore.kernel.org/lkml/Y3b9AAEKp2Vr3e6O@sol.localdomain/ > > Cc: Eric Biggers <ebiggers@kernel.org> > > Signed-off-by: Alexander Potapenko <glider@google.com> > > --- > > arch/x86/include/asm/thread_info.h | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h > > index f0cb881c1d690..f1cccba52eb97 100644 > > --- a/arch/x86/include/asm/thread_info.h > > +++ b/arch/x86/include/asm/thread_info.h > > @@ -163,7 +163,12 @@ struct thread_info { > > * GOOD_FRAME if within a frame > > * BAD_STACK if placed across a frame boundary (or outside stack) > > * NOT_STACK unable to determine (no frame pointers, etc) > > + * > > + * This function reads pointers from the stack and dereferences them. The > > + * pointers may not have their KMSAN shadow set up properly, which may result > > + * in false positive reports. Disable instrumentation to avoid those. > > */ > > +__no_kmsan_checks > > static inline int arch_within_stack_frames(const void * const stack, > > const void * const stackend, > > const void *obj, unsigned long len) > > Seems OK; but now I'm confused as to the exact distinction between > __no_sanitize_memory and __no_kmsan_checks. > > The comments there about seem to suggest __no_sanitize_memory ensures no > instrumentation at all, and __no_kmsan_checks some instrumentation but > doesn't actually check anything -- so what's left then?
__no_sanitize_memory prohibits all instrumentation whatsoever, whereas __no_kmsan_checks adds instrumentation that suppresses potential false positives around this function.
Quoting include/linux/compiler-clang.h:
/* * The __no_kmsan_checks attribute ensures that a function does not produce * false positive reports by: * - initializing all local variables and memory stores in this function; * - skipping all shadow checks; * - passing initialized arguments to this function's callees. */
Does this answer your question?
-- 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
| |