On Sun, 26 Feb 2023 at 12:00, Borislav Petkov <bp@xxxxxxxxx> wrote: > > On Sat, Feb 25, 2023 at 09:03:40PM -0800, Andrew Morton wrote: > > --- a/mm/kasan/shadow.c~kasan-emit-different-calls-for-instrumentable-memintrinsics > > +++ b/mm/kasan/shadow.c > > @@ -107,6 +107,17 @@ void *__asan_memcpy(void *dest, const void *src, size_t len) > > } > > EXPORT_SYMBOL(__asan_memcpy); > > > > +#ifdef CONFIG_KASAN_SW_TAGS > > +void *__hwasan_memset(void *addr, int c, size_t len) __alias(__asan_memset); > > +EXPORT_SYMBOL(__hwasan_memset); > > +#ifdef __HAVE_ARCH_MEMMOVE > > +void *__hwasan_memmove(void *dest, const void *src, size_t len) __alias(__asan_memmove); > > +EXPORT_SYMBOL(__hwasan_memmove); > > +#endif > > +void *__hwasan_memcpy(void *dest, const void *src, size_t len) __alias(__asan_memcpy); > > +EXPORT_SYMBOL(__hwasan_memcpy); > > Any particular reason those exports are not _GPL? To match lib/string.c: $> grep EXPORT_SYMBOL lib/string.c ... EXPORT_SYMBOL(memset); ... EXPORT_SYMBOL(memcpy); EXPORT_SYMBOL(memmove); ... Note that these __asan/__hwasan calls are generated by the compiler, in place of the above. On a more fundamental level, KASAN is low level enough that being _GPL would probably cause headaches for valid use cases. For example, so that vendors can use KASAN on their however licensed modules - wherever those non-GPL modules may be used, precluding use of KASAN there would make the quality of these things even worse. Thanks, -- Marco
