From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Kees Cook <kees@kernel.org>
Cc: "Mickaël Salaün" <mic@digikod.net>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Stephen Rothwell" <sfr@canb.auug.org.au>,
"Linux Next Mailing List" <linux-next@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
linux-security-module@vger.kernel.org,
"Günther Noack" <gnoack@google.com>
Subject: Re: linux-next: Tree for May 16 (security/landlock/ruleset.c)
Date: Tue, 20 May 2025 17:01:51 +0300 [thread overview]
Message-ID: <aCyLT2qr_7iJJHm6@black.fi.intel.com> (raw)
In-Reply-To: <202505191212.61EE1AE80@keescook>
On Mon, May 19, 2025 at 12:15:30PM -0700, Kees Cook wrote:
> On Mon, May 19, 2025 at 08:41:17PM +0200, Mickaël Salaün wrote:
...
> >From 6fbf66fdfd0a7dac809b77faafdd72c60112bb8d Mon Sep 17 00:00:00 2001
> From: Kees Cook <kees@kernel.org>
> Date: Mon, 19 May 2025 11:52:06 -0700
> Subject: [PATCH] string.h: Provide basic sanity checks for fallback memcpy()
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Instead of defining memcpy() in terms of __builtin_memcpy() deep
> in arch/x86/include/asm/string_32.h, notice that it is needed up in
> the general string.h, as done with other common C String APIs. This
> allows us to add basic sanity checking for pathological "size"
> arguments to memcpy(). Besides the run-time checking benefit, this
> avoids GCC trying to be very smart about value range tracking[1] when
> CONFIG_PROFILE_ALL_BRANCHES=y but FORTIFY_SOURCE=n.
>
> Link: https://lore.kernel.org/all/202505191117.C094A90F88@keescook/ [1]
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/all/202501040747.S3LYfvYq-lkp@intel.com/
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Closes: https://lore.kernel.org/all/e3754f69-1dea-4542-8de0-a567a14fb95b@infradead.org/
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> Cc: "Mickaël Salaün" <mic@digikod.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: <x86@kernel.org>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Uros Bizjak <ubizjak@gmail.com>
> Cc: <linux-hardening@vger.kernel.org>
> ---
> arch/x86/include/asm/string_32.h | 6 ------
> include/linux/string.h | 13 +++++++++++++
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/include/asm/string_32.h b/arch/x86/include/asm/string_32.h
> index e9cce169bb4c..74397c95fa37 100644
> --- a/arch/x86/include/asm/string_32.h
> +++ b/arch/x86/include/asm/string_32.h
> @@ -145,12 +145,6 @@ static __always_inline void *__constant_memcpy(void *to, const void *from,
> #define __HAVE_ARCH_MEMCPY
> extern void *memcpy(void *, const void *, size_t);
>
> -#ifndef CONFIG_FORTIFY_SOURCE
> -
> -#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
> -
> -#endif /* !CONFIG_FORTIFY_SOURCE */
> -
> #define __HAVE_ARCH_MEMMOVE
> void *memmove(void *dest, const void *src, size_t n);
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 01621ad0f598..ffcee31a14f9 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -3,6 +3,7 @@
> #define _LINUX_STRING_H_
>
> #include <linux/args.h>
> +#include <linux/bug.h>
In case you are go with this change, please keep the headers in order.
> #include <linux/array_size.h>
(should be located here)
> #include <linux/cleanup.h> /* for DEFINE_FREE() */
> #include <linux/compiler.h> /* for inline */
> @@ -390,7 +391,19 @@ static inline const char *kbasename(const char *path)
>
> #if !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) && defined(CONFIG_FORTIFY_SOURCE)
> #include <linux/fortify-string.h>
> +#else
> +/* Basic sanity checking even without FORTIFY_SOURCE */
> +# ifndef __HAVE_ARCH_MEMCPY
> +# define memcpy(t, f, n) \
> + do { \
> + typeof(n) __n = (n); \
> + /* Skip impossible sizes. */ \
> + if (!WARN_ON(__n < 0 || __n == SIZE_MAX)) \
> + __builtin_memcpy(t, f, __n); \
> + } while (0)
> +# endif
> #endif
> +
> #ifndef unsafe_memcpy
> #define unsafe_memcpy(dst, src, bytes, justification) \
> memcpy(dst, src, bytes)
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-05-20 14:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-16 10:24 linux-next: Tree for May 16 Stephen Rothwell
2025-05-16 21:03 ` linux-next: Tree for May 16 [drivers/platform/x86/amd/hsmp/hsmp_acpi.ko] Randy Dunlap
2025-05-17 2:54 ` linux-next: Tree for May 16 (security/landlock/ruleset.c) Randy Dunlap
2025-05-19 15:29 ` Mickaël Salaün
2025-05-19 18:19 ` Kees Cook
2025-05-19 18:41 ` Mickaël Salaün
2025-05-19 19:15 ` Kees Cook
2025-05-19 20:26 ` Randy Dunlap
2025-05-20 16:44 ` Kees Cook
2025-05-20 14:01 ` Andy Shevchenko [this message]
2025-05-20 16:47 ` Kees Cook
2025-05-20 14:45 ` Mickaël Salaün
2025-05-20 15:48 ` Randy Dunlap
2025-05-20 16:15 ` Kees Cook
2025-05-19 21:02 ` linux-next: Tree for May 16 (futex kernel-doc) Randy Dunlap
2025-05-20 7:59 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aCyLT2qr_7iJJHm6@black.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=gnoack@google.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.