All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Peter Oberparleiter <oberpar@linux.ibm.com>,
	kernel test robot <lkp@intel.com>,
	Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
	Bill Wendling <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>,
	llvm@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2] gcov: Disable GCOV_PROFILE_ALL on 32-bit UML with Clang 20/21
Date: Wed, 8 Apr 2026 20:07:18 -0700	[thread overview]
Message-ID: <202604082006.FF907B56F6@keescook> (raw)
In-Reply-To: <20260408220334.GA3962465@ax162>

On Wed, Apr 08, 2026 at 03:03:34PM -0700, Nathan Chancellor wrote:
> On Wed, Apr 08, 2026 at 09:26:12AM -0700, Kees Cook wrote:
> > Clang 20 and 21 miscompute __builtin_object_size() when -fprofile-arcs
> > is active on 32-bit UML targets, which passes incorrect object size
> > calculations for local variables through always_inline copy_to_user()
> > and check_copy_size(), causing spurious compile-time errors:
> > 
> >   include/linux/ucopysize.h:52:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small
> > 
> > The regression was introduced in LLVM commit 02b8ee281947 ("[llvm]
> > Improve llvm.objectsize computation by computing GEP, alloca and malloc
> > parameters bound"), which shipped in Clang 20. It was fixed in LLVM
> > by commit 45b697e610fd ("[MemoryBuiltins] Consider index type size
> > when aggregating gep offsets"), which was backported to the LLVM 22.x
> > release branch.
> > 
> > The bug requires 32-bit UML + GCOV_PROFILE_ALL (which uses -fprofile-arcs),
> > though the exact trigger depends on optimizer decisions influenced by other
> > enabled configs.
> > 
> > Prevent the broken combination by disabling GCOV_PROFILE_ALL on 32-bit
> > UML when using Clang 20.x or 21.x.
> > 
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202604030531.O6FveVgn-lkp@intel.com/
> > Assisted-by: Claude:claude-opus-4-6[1m]
> > Signed-off-by: Kees Cook <kees@kernel.org>
> > ---
> >  v2: fixed typo in version comparison: needed < not <= (Sashiko)
> >  v1: https://lore.kernel.org/lkml/20260408005958.work.271-kees@kernel.org/
> > Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
> > Cc: Nathan Chancellor <nathan@kernel.org>
> > Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
> > Cc: Bill Wendling <morbo@google.com>
> > Cc: Justin Stitt <justinstitt@google.com>
> > Cc: <llvm@lists.linux.dev>
> > ---
> >  kernel/gcov/Kconfig | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig
> > index 04f4ebdc3cf5..56abff785654 100644
> > --- a/kernel/gcov/Kconfig
> > +++ b/kernel/gcov/Kconfi
> > @@ -42,6 +42,9 @@ config GCOV_PROFILE_ALL
> >  	depends on !COMPILE_TEST
> >  	depends on GCOV_KERNEL
> >  	depends on ARCH_HAS_GCOV_PROFILE_ALL
> 
> Would it be better to avoid selecting this symbol in arch/um/Kconfig
> when we have this condition?
> 
> > +	# Clang 20 & 21 miscompute __builtin_object_size() under -fprofile-arcs
> > +	# on 32-bit UML, causing spurious compile-time errors in check_copy_size().
> > +	depends on !(UML && !64BIT && CC_IS_CLANG && CLANG_VERSION >= 200000 && CLANG_VERSION < 220100)
> 
> Given that you have an inclusive range above 0, you could drop the CC_IS_CLANG.
> 
> With the suggestion above it would just become:
> 
> diff --git a/arch/um/Kconfig b/arch/um/Kconfig
> index 098cda44db22..d9541d13d9eb 100644
> --- a/arch/um/Kconfig
> +++ b/arch/um/Kconfig
> @@ -11,7 +11,9 @@ config UML
>  	select ARCH_HAS_CACHE_LINE_SIZE
>  	select ARCH_HAS_CPU_FINALIZE_INIT
>  	select ARCH_HAS_FORTIFY_SOURCE
> -	select ARCH_HAS_GCOV_PROFILE_ALL
> +	# Clang 20 & 21 miscompute __builtin_object_size() under -fprofile-arcs
> +	# on 32-bit, causing spurious compile-time errors in check_copy_size().
> +	select ARCH_HAS_GCOV_PROFILE_ALL if !(!64BIT && CLANG_VERSION >= 200000 && CLANG_VERSION < 220100)
>  	select ARCH_HAS_KCOV
>  	select ARCH_HAS_STRNCPY_FROM_USER
>  	select ARCH_HAS_STRNLEN_USER

That is a lot nicer; yeah. I will use this and send a v3.

-- 
Kees Cook

      reply	other threads:[~2026-04-09  3:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08 16:26 [PATCH v2] gcov: Disable GCOV_PROFILE_ALL on 32-bit UML with Clang 20/21 Kees Cook
2026-04-08 22:03 ` Nathan Chancellor
2026-04-09  3:07   ` Kees Cook [this message]

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=202604082006.FF907B56F6@keescook \
    --to=kees@kernel.org \
    --cc=justinstitt@google.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=oberpar@linux.ibm.com \
    /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.