From: Nathan Chancellor <nathan@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: Linus Torvalds <torvalds@linuxfoundation.org>,
kernel test robot <lkp@intel.com>,
syzbot+5245cb609175fb6e8122@syzkaller.appspotmail.com,
Miguel Ojeda <ojeda@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Ard Biesheuvel <ardb@kernel.org>, Marco Elver <elver@google.com>,
Hou Wenlong <houwenlong.hwl@antgroup.com>,
"Kirill A . Shutemov" <kas@kernel.org>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Wei Yang <richard.weiyang@gmail.com>,
Sami Tolvanen <samitolvanen@google.com>,
Arnd Bergmann <arnd@arndb.de>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Jan Hendrik Farr <kernel@jfarr.cc>,
Uros Bizjak <ubizjak@gmail.com>,
Marc Herbert <Marc.Herbert@linux.intel.com>,
Yafang Shao <laoar.shao@gmail.com>,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2] compiler_types: Provide __no_kstack_erase to disable coverage only on Clang
Date: Tue, 29 Jul 2025 16:46:04 -0700 [thread overview]
Message-ID: <20250729234604.GA921387@ax162> (raw)
In-Reply-To: <20250729234055.it.233-kees@kernel.org>
On Tue, Jul 29, 2025 at 04:41:00PM -0700, Kees Cook wrote:
> In order to support Clang's stack depth tracking (for Linux's kstack_erase
> feature), the coverage sanitizer needed to be disabled for __init (and
> __head) section code. Doing this universally (i.e. for GCC too) created
> a number of unexpected problems, ranging from changes to inlining logic
> to failures to DCE code on earlier GCC versions.
>
> Since this change is only needed for Clang, specialize it so that GCC
> doesn't see the change as it isn't needed there (the GCC implementation
> of kstack_erase uses a GCC plugin that removes stack depth tracking
> instrumentation from __init sections during a late pass in the IR).
>
> Successfully build and boot tested with GCC 12 and Clang 22.
>
> Fixes: 381a38ea53d2 ("init.h: Disable sanitizer coverage for __init and __head")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202507270258.neWuiXLd-lkp@intel.com/
> Reported-by: syzbot+5245cb609175fb6e8122@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/6888d004.a00a0220.26d0e1.0004.GAE@google.com/
> Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> arch/x86/include/asm/init.h | 2 +-
> include/linux/compiler-clang.h | 3 +++
> include/linux/compiler_types.h | 4 ++++
> include/linux/init.h | 2 +-
> 4 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/init.h b/arch/x86/include/asm/init.h
> index 6bfdaeddbae8..5a68e9db6518 100644
> --- a/arch/x86/include/asm/init.h
> +++ b/arch/x86/include/asm/init.h
> @@ -5,7 +5,7 @@
> #if defined(CONFIG_CC_IS_CLANG) && CONFIG_CLANG_VERSION < 170000
> #define __head __section(".head.text") __no_sanitize_undefined __no_stack_protector
> #else
> -#define __head __section(".head.text") __no_sanitize_undefined __no_sanitize_coverage
> +#define __head __section(".head.text") __no_sanitize_undefined __no_kstack_erase
> #endif
>
> struct x86_mapping_info {
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index 4fc8e26914ad..fa4ffe037bc7 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -89,6 +89,9 @@
> #define __no_sanitize_coverage
> #endif
>
> +/* Only Clang needs to disable the coverage sanitizer for kstack_erase. */
IMO, this comment does not add much now that this is separated from the
dummy definition of __no_kstack_erase but it's probably not worth
changing in a new revision if Linus wants to take this directly.
> +#define __no_kstack_erase __no_sanitize_coverage
> +
> #if __has_feature(shadow_call_stack)
> # define __noscs __attribute__((__no_sanitize__("shadow-call-stack")))
> #endif
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index 2b77d12e07b2..16755431fc11 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -424,6 +424,10 @@ struct ftrace_likely_data {
> # define randomized_struct_fields_end
> #endif
>
> +#ifndef __no_kstack_erase
> +# define __no_kstack_erase
> +#endif
> +
> #ifndef __noscs
> # define __noscs
> #endif
> diff --git a/include/linux/init.h b/include/linux/init.h
> index c65a050d52a7..a60d32d227ee 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -51,7 +51,7 @@
> discard it in modules) */
> #define __init __section(".init.text") __cold __latent_entropy \
> __noinitretpoline \
> - __no_sanitize_coverage
> + __no_kstack_erase
> #define __initdata __section(".init.data")
> #define __initconst __section(".init.rodata")
> #define __exitdata __section(".exit.data")
> --
> 2.34.1
>
next prev parent reply other threads:[~2025-07-29 23:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 23:41 Kees Cook
2025-07-29 23:46 ` Nathan Chancellor [this message]
2025-07-29 23:46 ` Marco Elver
2025-07-30 0:39 ` Kees Cook
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=20250729234604.GA921387@ax162 \
--to=nathan@kernel.org \
--cc=Marc.Herbert@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=christophe.leroy@csgroup.eu \
--cc=dave.hansen@linux.intel.com \
--cc=elver@google.com \
--cc=houwenlong.hwl@antgroup.com \
--cc=hpa@zytor.com \
--cc=justinstitt@google.com \
--cc=kas@kernel.org \
--cc=kees@kernel.org \
--cc=kernel@jfarr.cc \
--cc=laoar.shao@gmail.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=masahiroy@kernel.org \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=richard.weiyang@gmail.com \
--cc=samitolvanen@google.com \
--cc=syzbot+5245cb609175fb6e8122@syzkaller.appspotmail.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linuxfoundation.org \
--cc=ubizjak@gmail.com \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®