Messages in this thread | | | Date | Mon, 28 Mar 2022 15:12:14 +0200 | From | Jakub Jelinek <> | Subject | Re: clang memcpy calls |
| |
On Mon, Mar 28, 2022 at 01:55:38PM +0100, Mark Rutland wrote: > > If coexistence of instrumented and non-instrumented memcpy etc. was the goal > > (it clearly wasn't), then the sanitizer libraries wouldn't be overriding > > memcpy calls, but instead the compiler would redirect calls to memcpy in > > instrumented functions to say __asan_memcpy which then would be > > instrumented. > > FWIW, I think that approach would be fine for kernel usage. > > > > Given the standard doesn't say *anything* about instrumentation, what does GCC > > > *require* instrumentation-wise of the memcpy implementation? What happens *in > > > practice* today? > > > > > > For example, is the userspace implementation of memcpy() instrumented for > > > AddressSanitizer, or not? > > > > It is, for all functions, whether compiled with -fsanitize=address or not, > > if user app is linked with -fsanitize=address, libasan is linked in and > > overrides the libc memcpy with its instrumented version. > > Thanks for confirming! Just to check, how does libasan prevent recursing > within itself on implicitly generated calls to memcpy and friends? Is > anything special done to build the libasan code, is that all asm, or > something else?
Generally, most of the libasan wrappers look like do something call the original libc function (address from dlsym/dlvsym) do something and the "do something" code isn't that complicated. The compiler doesn't add calls to memcpy/memset etc. just to screw up users, they are added for a reason, such as copying or clearing very large aggregates (including for passing them by value), without -Os it will rarely use calls for smaller sizes and will instead expand them inline. For malloc and the like wrappers I think it uses some TLS recursion counters so that say malloc called from dlsym doesn't cause problems.
Now, one way for the kernel to make kasan work (more) reliably even with existing compilers without special tweaks for this might be if those calls to no_sanitize_address code aren't mixed with sanitized code all the time might be set some per-thread flag when starting a "no sanitized" code execution and clear it at the end of the region (or vice versa) and test those flags in the kernel's memcpy/memset etc. implementation to decide if they should be sanitized or not. As KASAN is (hopefully) just a kernel debugging aid and not something meant for production (in the userspace at least GCC strongly recommends against using the sanitizers in production), perhaps allocating one per-thread bool or int and changing it in a few spots and testing in the library functions might be acceptable.
Jakub
| |