From: Randy Dunlap <rdunlap@infradead.org>
To: Nathan Chancellor <nathan@kernel.org>, Kees Cook <kees@outflux.net>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Kees Cook <kees@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Sami Tolvanen <samitolvanen@google.com>,
Linus Walleij <linus.walleij@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
Puranjay Mohan <puranjay@kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Jonathan Corbet <corbet@lwn.net>,
x86@kernel.org, linux-doc@vger.kernel.org,
linux-kbuild@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, llvm@lists.linux.dev,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH 5/5] kcfi: Rename CONFIG_CFI_CLANG to CONFIG_CFI
Date: Wed, 27 Aug 2025 00:35:12 -0700 [thread overview]
Message-ID: <56c2b1ce-00a4-403c-9927-79bfd9a23574@infradead.org> (raw)
In-Reply-To: <20250827013444.GA2859318@ax162>
On 8/26/25 6:34 PM, Nathan Chancellor wrote:
> On Mon, Aug 25, 2025 at 03:31:34PM -0400, Kees Cook wrote:
>> On August 25, 2025 1:00:22 PM EDT, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>>> On Mon, Aug 25, 2025 at 5:35 PM Kees Cook <kees@kernel.org> wrote:
>>>>
>>>> Yeah, that's a good idea. What the right way to do that?
>>>>
>>>> config CFI_CLANG
>>>> bool "Use Clang's Control Flow Integrity (CFI)"
>>>> depends on ARCH_SUPPORTS_CFI
>>>> select CFI
>>>>
>>>> ?
>>>
>>> I don't recall what is the idiomatic solution for renames, but I
>>> remember Linus talking about this topic and about avoiding losing old
>>> values if possible (perhaps getting a new question in `oldconfig` is
>>> OK as long as the `olddefconfig` respects the old value).
>>>
>>> I think your suggestion above will still make it appear twice in
>>> `menuconfig` -- there may be a way to play with visibility to make it
>>> better.
>>>
>>> A simple possibility I can think of (assuming it works) is having the
>>> CFI symbol for the time being introduced just as a `def_bool
>>> CFI_CLANG` for a few releases so that people get the new one in their
>>> configs.
>>
>> Ah, I think this works:
>>
>> config CFI_CLANG
>> bool
>>
>> config CFI
>> bool "...."
>> default CFI_CLANG
>>
>> I will add that for v2.
>
> That does not appear to work for me. I applied
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index c25a45d9aa96..0d3ed03c76c2 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -876,8 +876,12 @@ config ARCH_SUPPORTS_CFI
> config ARCH_USES_CFI_TRAPS
> bool
>
> +config CFI_CLANG
> + bool
> +
> config CFI
> bool "Use Kernel Control Flow Integrity (kCFI)"
> + default CFI_CLANG
> depends on ARCH_SUPPORTS_CFI
> depends on $(cc-option,-fsanitize=kcfi)
> help
>
> on top of this series and
>
> CONFIG_CFI_CLANG=y
> # CONFIG_CFI_ICALL_NORMALIZE_INTEGERS is not set
> # CONFIG_CFI_PERMISSIVE is not set
>
> gets turned into
>
> # CONFIG_CFI is not set
>
> after olddefconfig. CONFIG_CFI_CLANG has to be user selectable with a
Could/did you test with 'oldconfig' instead?
olddefconfig is going to use the default value from the Kconfig file,
which if CFI_CLANG which is undefined/No/Not set.
oldconfig will use the old value from the .config file.
> prompt but the only solution I can think of at the moment results in a
> duplicate prompt for Clang.
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index c25a45d9aa96..93bf9b41a9de 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -876,8 +876,17 @@ config ARCH_SUPPORTS_CFI
> config ARCH_USES_CFI_TRAPS
> bool
>
> +config CFI_CLANG
> + bool "Use Kernel Control Flow Integrity (kCFI) - Transitional" if CC_IS_CLANG
> + select CFI
> + depends on ARCH_SUPPORTS_CFI
> + depends on $(cc-option,-fsanitize=kcfi)
> + help
> + This is a transitional symbol to CONFIG_CFI, see its help text
> + for more information.
> +
> config CFI
> - bool "Use Kernel Control Flow Integrity (kCFI)"
> + bool "Use Kernel Control Flow Integrity (kCFI)" if CC_IS_GCC
> depends on ARCH_SUPPORTS_CFI
> depends on $(cc-option,-fsanitize=kcfi)
> help
>
> Maybe that does not matter for the sake of keeping things working?
> Otherwise, we could just keep things as they are with the patch set and
> expect people to actually use oldconfig or diff the results of
> olddefconfig (which I think is good practice anyways).
>
> Cheers,
> Nathan
>
--
~Randy
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-08-27 7:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-25 14:25 [PATCH 0/5] kcfi: Prepare for GCC support Kees Cook
2025-08-25 14:25 ` [PATCH 1/5] compiler_types.h: Move __nocfi out of compiler-specific header Kees Cook
2025-08-27 19:46 ` Nathan Chancellor
2025-08-25 14:25 ` [PATCH 2/5] x86/traps: Clarify KCFI instruction layout Kees Cook
2025-08-25 14:25 ` [PATCH 3/5] x86/cfi: Add option for cfi=debug bootparam Kees Cook
2025-08-25 15:34 ` Kees Cook
2025-08-25 15:59 ` Peter Zijlstra
2025-08-25 16:16 ` Kees Cook
2025-08-27 19:57 ` Nathan Chancellor
2025-08-29 1:49 ` Kees Cook
2025-08-25 14:25 ` [PATCH 4/5] x86/cfi: Remove __noinitretpoline and __noretpoline Kees Cook
2025-08-25 14:25 ` [PATCH 5/5] kcfi: Rename CONFIG_CFI_CLANG to CONFIG_CFI Kees Cook
2025-08-25 15:01 ` Miguel Ojeda
2025-08-25 15:35 ` Kees Cook
2025-08-25 17:00 ` Miguel Ojeda
2025-08-25 19:31 ` Kees Cook
2025-08-27 1:34 ` Nathan Chancellor
2025-08-27 7:35 ` Randy Dunlap [this message]
2025-08-27 19:38 ` Nathan Chancellor
2025-08-28 6:14 ` Randy Dunlap
2025-08-28 12:11 ` Miguel Ojeda
2025-08-28 20:19 ` Nathan Chancellor
2025-08-28 20:32 ` Kees Cook
2025-08-28 22:22 ` Nathan Chancellor
2025-08-28 22:55 ` Miguel Ojeda
2025-08-28 22:46 ` Miguel Ojeda
2025-08-26 21:49 ` Jeff Johnson
2025-08-28 12:08 ` Linus Walleij
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=56c2b1ce-00a4-403c-9927-79bfd9a23574@infradead.org \
--to=rdunlap@infradead.org \
--cc=corbet@lwn.net \
--cc=dwmw2@infradead.org \
--cc=kees@kernel.org \
--cc=kees@outflux.net \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=nathan@kernel.org \
--cc=peterz@infradead.org \
--cc=puranjay@kernel.org \
--cc=samitolvanen@google.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;
as well as URLs for NNTP newsgroup(s).