[PATCH] string: use __builtin_memcpy() in strlcpy/strlcat

[PATCH] string: use __builtin_memcpy() in strlcpy/strlcat

[Alexander Potapenko]

lib/string.c is built with -ffreestanding, which prevents the compiler
from replacing certain functions with calls to their library versions.

On the other hand, this also prevents Clang and GCC from instrumenting
calls to memcpy() when building with KASAN, KCSAN or KMSAN:
 - KASAN normally replaces memcpy() with __asan_memcpy() with the
   additional cc-param,asan-kernel-mem-intrinsic-prefix=1;
 - KCSAN and KMSAN replace memcpy() with __tsan_memcpy() and
   __msan_memcpy() by default.

To let the tools catch memory accesses from strlcpy/strlcat, replace
the calls to memcpy() with __builtin_memcpy(), which KASAN, KCSAN and
KMSAN are able to replace even in -ffreestanding mode.

This preserves the behavior in normal builds (__builtin_memcpy() ends up
being replaced with memcpy()), and does not introduce new instrumentation
in unwanted places, as strlcpy/strlcat are already instrumented.

Suggested-by: Marco Elver <elver@google.com>
Signed-off-by: Alexander Potapenko <glider@google.com>
Link: https://lore.kernel.org/all/20230224085942.1791837-1-elver@google.com/
---
 lib/string.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/string.c b/lib/string.c
index 3d55ef8901068..be26623953d2e 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -110,7 +110,7 @@ size_t strlcpy(char *dest, const char *src, size_t size)
 
 	if (size) {
 		size_t len = (ret >= size) ? size - 1 : ret;
-		memcpy(dest, src, len);
+		__builtin_memcpy(dest, src, len);
 		dest[len] = '\0';
 	}
 	return ret;
@@ -260,7 +260,7 @@ size_t strlcat(char *dest, const char *src, size_t count)
 	count -= dsize;
 	if (len >= count)
 		len = count-1;
-	memcpy(dest, src, len);
+	__builtin_memcpy(dest, src, len);
 	dest[len] = 0;
 	return res;
 }
-- 
2.40.0.634.g4ca3ef3211-goog

Re: [PATCH] string: use __builtin_memcpy() in strlcpy/strlcat

[Marco Elver]

On Mon, 24 Apr 2023 at 13:23, Alexander Potapenko <glider@google.com> wrote:
>
> lib/string.c is built with -ffreestanding, which prevents the compiler
> from replacing certain functions with calls to their library versions.
>
> On the other hand, this also prevents Clang and GCC from instrumenting
> calls to memcpy() when building with KASAN, KCSAN or KMSAN:
>  - KASAN normally replaces memcpy() with __asan_memcpy() with the
>    additional cc-param,asan-kernel-mem-intrinsic-prefix=1;
>  - KCSAN and KMSAN replace memcpy() with __tsan_memcpy() and
>    __msan_memcpy() by default.
>
> To let the tools catch memory accesses from strlcpy/strlcat, replace
> the calls to memcpy() with __builtin_memcpy(), which KASAN, KCSAN and
> KMSAN are able to replace even in -ffreestanding mode.
>
> This preserves the behavior in normal builds (__builtin_memcpy() ends up
> being replaced with memcpy()), and does not introduce new instrumentation
> in unwanted places, as strlcpy/strlcat are already instrumented.
>
> Suggested-by: Marco Elver <elver@google.com>
> Signed-off-by: Alexander Potapenko <glider@google.com>
> Link: https://lore.kernel.org/all/20230224085942.1791837-1-elver@google.com/

Reviewed-by: Marco Elver <elver@google.com>

Looks reasonable.

> ---
>  lib/string.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/string.c b/lib/string.c
> index 3d55ef8901068..be26623953d2e 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -110,7 +110,7 @@ size_t strlcpy(char *dest, const char *src, size_t size)
>
>         if (size) {
>                 size_t len = (ret >= size) ? size - 1 : ret;
> -               memcpy(dest, src, len);
> +               __builtin_memcpy(dest, src, len);
>                 dest[len] = '\0';
>         }
>         return ret;
> @@ -260,7 +260,7 @@ size_t strlcat(char *dest, const char *src, size_t count)
>         count -= dsize;
>         if (len >= count)
>                 len = count-1;
> -       memcpy(dest, src, len);
> +       __builtin_memcpy(dest, src, len);
>         dest[len] = 0;
>         return res;
>  }
> --
> 2.40.0.634.g4ca3ef3211-goog
>

Re: [PATCH] string: use __builtin_memcpy() in strlcpy/strlcat

[Kees Cook]

On Mon, Apr 24, 2023 at 01:23:13PM +0200, Alexander Potapenko wrote:
> lib/string.c is built with -ffreestanding, which prevents the compiler
> from replacing certain functions with calls to their library versions.
> 
> On the other hand, this also prevents Clang and GCC from instrumenting
> calls to memcpy() when building with KASAN, KCSAN or KMSAN:
>  - KASAN normally replaces memcpy() with __asan_memcpy() with the
>    additional cc-param,asan-kernel-mem-intrinsic-prefix=1;
>  - KCSAN and KMSAN replace memcpy() with __tsan_memcpy() and
>    __msan_memcpy() by default.
> 
> To let the tools catch memory accesses from strlcpy/strlcat, replace
> the calls to memcpy() with __builtin_memcpy(), which KASAN, KCSAN and
> KMSAN are able to replace even in -ffreestanding mode.
> 
> This preserves the behavior in normal builds (__builtin_memcpy() ends up
> being replaced with memcpy()), and does not introduce new instrumentation
> in unwanted places, as strlcpy/strlcat are already instrumented.
> 
> Suggested-by: Marco Elver <elver@google.com>
> Signed-off-by: Alexander Potapenko <glider@google.com>
> Link: https://lore.kernel.org/all/20230224085942.1791837-1-elver@google.com/
> ---
>  lib/string.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/string.c b/lib/string.c
> index 3d55ef8901068..be26623953d2e 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -110,7 +110,7 @@ size_t strlcpy(char *dest, const char *src, size_t size)
>  
>  	if (size) {
>  		size_t len = (ret >= size) ? size - 1 : ret;
> -		memcpy(dest, src, len);
> +		__builtin_memcpy(dest, src, len);
>  		dest[len] = '\0';
>  	}
>  	return ret;
> @@ -260,7 +260,7 @@ size_t strlcat(char *dest, const char *src, size_t count)
>  	count -= dsize;
>  	if (len >= count)
>  		len = count-1;
> -	memcpy(dest, src, len);
> +	__builtin_memcpy(dest, src, len);
>  	dest[len] = 0;
>  	return res;

I *think* this isn't a problem for CONFIG_FORTIFY, since these will be
replaced and checked separately -- but it still seems strange that you
need to explicitly use __builtin_memcpy.

Does this end up changing fortify coverage?

-- 
Kees Cook

Re: [PATCH] string: use __builtin_memcpy() in strlcpy/strlcat

[Alexander Potapenko]

>
> I *think* this isn't a problem for CONFIG_FORTIFY, since these will be
> replaced and checked separately -- but it still seems strange that you
> need to explicitly use __builtin_memcpy.
>
> Does this end up changing fortify coverage?

Is fortify relevant here? Note that the whole file is compiled with
__NO_FORTIFY.

Re: [PATCH] string: use __builtin_memcpy() in strlcpy/strlcat

[Alexander Potapenko]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On Fri, Apr 28, 2023 at 3:48 PM Alexander Potapenko <glider@google.com>
wrote:

> >FORTIFY_SOURCE  glidear
> > I *think* this isn't a problem for CONFIG_FORTIFY, since these will be
> > replaced and checked separately -- but it still seems strange that you
> > need to explicitly use __builtin_memcpy.
>
>
Or did you mean we'd better use __underlying_memcpy() here instead? I am a
bit puzzled.

[-- Attachment #2: Type: text/html, Size: 757 bytes --]

Re: [PATCH] string: use __builtin_memcpy() in strlcpy/strlcat

[Alexander Potapenko]

On Wed, May 10, 2023 at 9:48 AM Alexander Potapenko <glider@google.com> wrote:
>
>
>
> On Fri, Apr 28, 2023 at 3:48 PM Alexander Potapenko <glider@google.com> wrote:
>>

>> > I *think* this isn't a problem for CONFIG_FORTIFY, since these will be
>> > replaced and checked separately -- but it still seems strange that you
>> > need to explicitly use __builtin_memcpy.
>>
>
> Or did you mean we'd better use __underlying_memcpy() here instead? I am a bit puzzled.

Kees told me offline that the patch in question is fine.
@Andrew, would it be possible to queue it for 6.4?

--
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

Re: [PATCH] string: use __builtin_memcpy() in strlcpy/strlcat

[Kees Cook]

On Fri, Apr 28, 2023 at 03:48:28PM +0200, Alexander Potapenko wrote:
> >
> > I *think* this isn't a problem for CONFIG_FORTIFY, since these will be
> > replaced and checked separately -- but it still seems strange that you
> > need to explicitly use __builtin_memcpy.
> >
> > Does this end up changing fortify coverage?
> 
> Is fortify relevant here? Note that the whole file is compiled with
> __NO_FORTIFY.

Yeah, agreed. I think I was just curious if that got verified. I'm good
with this.

Acked-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook