As mentioned in the https://lkml.org/lkml/2023/2/9/1182 thread, Linux kernel would like to have --param asan-kernel-mem-intrinsic-prefix=1 support which would use __asan_memcpy, __asan_memmove and __asan_memset with -fsanitize=kernel-address and __hwasan_memcpy, __hwasan_memmove and __hwasan_memset with -fsanitize=kernel-hwaddress instead of memcpy, memmove and memset calls in kasan instrumented functions, such that kernel memcpy/memmove/memset could remain uninstrumented for use in kernel functions with no_sanitize ("kernel-address").
Created attachment 54456 [details] gcc13-pr108777.patch Untested implementation.
Marco, is this what you are looking for?
(In reply to Jakub Jelinek from comment #2) > Marco, is this what you are looking for? Yes, looks good - the tests verify the behaviour I'd expect. Thanks!
Shouldn't this be an -f switch if it's an official compiler feature?
It is a similar tweak like many other asan tweaks which use params rather than switches.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:91b36d1c85ae3ad667d11c1ceeffc698126ab804 commit r13-5982-g91b36d1c85ae3ad667d11c1ceeffc698126ab804 Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Feb 14 12:10:09 2023 +0100 asan: Add --param=asan-kernel-mem-intrinsic-prefix= [PR108777] While in the -fsanitize=address case libasan overloads memcpy, memset, memmove and many other builtins, such that they are always instrumented, Linux kernel for -fsanitize=kernel-address recently changed or is changing, such that memcpy, memset and memmove actually aren't instrumented because they are often used also from no_sanitize ("kernel-address") functions and wants __{,hw,}asaN_{memcpy,memset,memmove} to be used instead for the instrumented calls. See e.g. the https://lkml.org/lkml/2023/2/9/1182 thread. Without appropriate support on the compiler side, that will mean any time a kernel-address instrumented function (most of them) calls memcpy/memset/memmove, they will not be instrumented and thus won't catch kernel bugs. Apparently clang 15 has a param for this. The following patch implements the same (except it is a usual GCC --param, not -mllvm argument) on the GCC side. I know this isn't a regression bugfix, but given that -fsanitize=kernel-address has a single project that uses it which badly wants this I think it would be worthwhile to make an exception and get this into GCC 13 rather than waiting another year, it won't affect non-kernel code, nor even the kernel unless the new parameter is used. 2023-02-14 Jakub Jelinek <jakub@redhat.com> PR sanitizer/108777 * params.opt (-param=asan-kernel-mem-intrinsic-prefix=): New param. * asan.h (asan_memfn_rtl): Declare. * asan.cc (asan_memfn_rtls): New variable. (asan_memfn_rtl): New function. * builtins.cc (expand_builtin): If param_asan_kernel_mem_intrinsic_prefix and function is kernel-{,hw}address sanitized, emit calls to __{,hw}asan_{memcpy,memmove,memset} rather than {memcpy,memmove,memset}. Use sanitize_flags_p (SANITIZE_ADDRESS) instead of flag_sanitize & SANITIZE_ADDRESS to check if asan_intercepted_p functions shouldn't be expanded inline. * gcc.dg/asan/pr108777-1.c: New test. * gcc.dg/asan/pr108777-2.c: New test. * gcc.dg/asan/pr108777-3.c: New test. * gcc.dg/asan/pr108777-4.c: New test. * gcc.dg/asan/pr108777-5.c: New test. * gcc.dg/asan/pr108777-6.c: New test. * gcc.dg/completion-3.c: Adjust expected multiline output.
Implemented for GCC 13.1 (to be released in April/May this year).
Thanks for the quick turnaround!