Re: [PATCH v2 13/48] kmsan: add KMSAN runtime core

[Peter Zijlstra]

On Tue, Mar 29, 2022 at 02:39:42PM +0200, Alexander Potapenko wrote:
> +/* Handle llvm.memmove intrinsic. */
> +void *__msan_memmove(void *dst, const void *src, uintptr_t n)
> +{
> +	void *result;
> +
> +	result = __memmove(dst, src, n);
> +	if (!n)
> +		/* Some people call memmove() with zero length. */
> +		return result;
> +	if (!kmsan_enabled || kmsan_in_runtime())
> +		return result;
> +
> +	kmsan_internal_memmove_metadata(dst, (void *)src, n);
> +
> +	return result;
> +}
> +EXPORT_SYMBOL(__msan_memmove);
> +
> +/* Handle llvm.memcpy intrinsic. */
> +void *__msan_memcpy(void *dst, const void *src, uintptr_t n)
> +{
> +	void *result;
> +
> +	result = __memcpy(dst, src, n);
> +	if (!n)
> +		/* Some people call memcpy() with zero length. */
> +		return result;
> +
> +	if (!kmsan_enabled || kmsan_in_runtime())
> +		return result;
> +
> +	/* Using memmove instead of memcpy doesn't affect correctness. */
> +	kmsan_internal_memmove_metadata(dst, (void *)src, n);
> +
> +	return result;
> +}
> +EXPORT_SYMBOL(__msan_memcpy);
> +
> +/* Handle llvm.memset intrinsic. */
> +void *__msan_memset(void *dst, int c, uintptr_t n)
> +{
> +	void *result;
> +
> +	result = __memset(dst, c, n);
> +	if (!kmsan_enabled || kmsan_in_runtime())
> +		return result;
> +
> +	kmsan_enter_runtime();
> +	/*
> +	 * Clang doesn't pass parameter metadata here, so it is impossible to
> +	 * use shadow of @c to set up the shadow for @dst.
> +	 */
> +	kmsan_internal_unpoison_memory(dst, n, /*checked*/ false);
> +	kmsan_leave_runtime();
> +
> +	return result;
> +}
> +EXPORT_SYMBOL(__msan_memset);

This, we need this same for KASAN. KASAN must be changed to have the
mem*() intrinsics emit __asan_mem*(), such that we can have
uninstrumented base functions.

Currently we seem to have the problem that when a noinstr function trips
one of those instrinsics it'll emit a call to an instrumented function,
which is a complete no-no.

Also see:

  https://lore.kernel.org/all/YjxTt3pFIcV3lt8I@xxxxxxx/T/#m2049a14be400d4ae2b54a1f7da3ede28b7fd7564

Given the helpful feedback there, Mark and me are going to unilaterally
break Kasan by deleting the existing wrappers.