From: Nathan Chancellor <nathan@kernel.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Kees Cook <kees@outflux.net>,
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 12:38:15 -0700 [thread overview]
Message-ID: <20250827193815.GA2293657@ax162> (raw)
In-Reply-To: <56c2b1ce-00a4-403c-9927-79bfd9a23574@infradead.org>
On Wed, Aug 27, 2025 at 12:35:12AM -0700, Randy Dunlap wrote:
> 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.
I am not sure I understand what you mean here. With the series as it is
or Kees's suggested fix, oldconfig still prompts the user to enable
CONFIG_CFI with CONFIG_CFI_CLANG=y in the old configuration. Both Miguel
and I allude to that being fine but it would be really nice if users
with CONFIG_CFI_CLANG=y were automatically transitioned to CONFIG_CFI=y
without any action on their part. That seems to be in line with how
Linus feels even as recently as this past merge window:
https://lore.kernel.org/CAHk-=wgO0Rx2LcYT4f75Xs46orbJ4JxO2jbAFQnVKDYAjV5HeQ@mail.gmail.com/
Another idea I had to avoid this is introducing CONFIG_CFI_GCC as a user
selectable symbol and making CONFIG_CFI the hidden symbol that both
compiler symbols select. After a couple of releases (or maybe the next
LTS), both CONFIG_CFI_CLANG and CONFIG_CFI_GCC could be eliminated with
CONFIG_CFI becoming user selectable, which would keep things working
since CONFIG_CFI=y will be present in the previous configuration.
Maybe it is not worth optimizing for this situation. I personally check
my configurations into git so that it is easy to deal with losing
things, as I have had my networking broken several times by new symbols
and dependencies that do not get handled well with olddefconfig.
> > 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
>
next prev parent reply other threads:[~2025-08-27 19: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
2025-08-27 19:38 ` Nathan Chancellor [this message]
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=20250827193815.GA2293657@ax162 \
--to=nathan@kernel.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=peterz@infradead.org \
--cc=puranjay@kernel.org \
--cc=rdunlap@infradead.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).