[PATCH v2 27/63] fortify: Move remaining fortify helpers into fortify-string.h
Francis Laniel
laniel_francis at privacyrequired.com
Wed Aug 18 19:05:58 UTC 2021
Hi.
Le mercredi 18 août 2021, 08:04:57 CEST Kees Cook a écrit :
> When commit a28a6e860c6c ("string.h: move fortified functions definitions
> in a dedicated header.") moved the fortify-specific code, some helpers
> were left behind. Moves the remaining fortify-specific helpers into
> fortify-string.h so they're together where they're used. This requires
> that any FORTIFY helper function prototypes be conditionally built to
> avoid "no prototype" warnings. Additionally removes unused helpers.
>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Francis Laniel <laniel_francis at privacyrequired.com>
> Cc: Daniel Axtens <dja at axtens.net>
> Cc: Vincenzo Frascino <vincenzo.frascino at arm.com>
> Cc: Andrey Konovalov <andreyknvl at google.com>
> Cc: Dan Williams <dan.j.williams at intel.com>
> Signed-off-by: Kees Cook <keescook at chromium.org>
> ---
> include/linux/fortify-string.h | 7 +++++++
> include/linux/string.h | 9 ---------
> lib/string_helpers.c | 2 ++
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h
> index c1be37437e77..7e67d02764db 100644
> --- a/include/linux/fortify-string.h
> +++ b/include/linux/fortify-string.h
> @@ -2,6 +2,13 @@
> #ifndef _LINUX_FORTIFY_STRING_H_
> #define _LINUX_FORTIFY_STRING_H_
>
> +#define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline))
> +#define __RENAME(x) __asm__(#x)
> +
> +void fortify_panic(const char *name) __noreturn __cold;
> +void __read_overflow(void) __compiletime_error("detected read beyond size
> of object (1st parameter)"); +void __read_overflow2(void)
> __compiletime_error("detected read beyond size of object (2nd parameter)");
> +void __write_overflow(void) __compiletime_error("detected write beyond
> size of object (1st parameter)");
>
> #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
> extern void *__underlying_memchr(const void *p, int c, __kernel_size_t
> size) __RENAME(memchr); diff --git a/include/linux/string.h
> b/include/linux/string.h
> index b48d2d28e0b1..9473f81b9db2 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -249,15 +249,6 @@ static inline const char *kbasename(const char *path)
> return tail ? tail + 1 : path;
> }
>
> -#define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline))
> -#define __RENAME(x) __asm__(#x)
> -
> -void fortify_panic(const char *name) __noreturn __cold;
> -void __read_overflow(void) __compiletime_error("detected read beyond size
> of object passed as 1st parameter"); -void __read_overflow2(void)
> __compiletime_error("detected read beyond size of object passed as 2nd
> parameter"); -void __read_overflow3(void) __compiletime_error("detected
> read beyond size of object passed as 3rd parameter"); -void
> __write_overflow(void) __compiletime_error("detected write beyond size of
> object passed as 1st parameter"); -
> #if !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) &&
> defined(CONFIG_FORTIFY_SOURCE) #include <linux/fortify-string.h>
> #endif
> diff --git a/lib/string_helpers.c b/lib/string_helpers.c
> index bde13612c25d..faa9d8e4e2c5 100644
> --- a/lib/string_helpers.c
> +++ b/lib/string_helpers.c
> @@ -883,9 +883,11 @@ char *strreplace(char *s, char old, char new)
> }
> EXPORT_SYMBOL(strreplace);
>
> +#ifdef CONFIG_FORTIFY_SOURCE
> void fortify_panic(const char *name)
> {
> pr_emerg("detected buffer overflow in %s\n", name);
> BUG();
> }
> EXPORT_SYMBOL(fortify_panic);
> +#endif /* CONFIG_FORTIFY_SOURCE */
If I remember correctly, I let these helpers in string.h because I thought
they could be used by code not related to fortify-string.h.
But you are right and I think it is better to have all the code related to one
feature in the same place.
I am happy to see the kernel is fortifying, and this contribution is good, so
here is what I can give:
Acked-by: Francis Laniel <laniel_francis at privacyrequired.com>
Best regards.
More information about the dri-devel
mailing list