linux-hardening - Re: [PATCH 5/5] kcfi: Rename CONFIG_CFI_CLANG to CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250828222218.GA3029249@ax162>
Date: Thu, 28 Aug 2025 15:22:18 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Kees Cook <kees@...nel.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Randy Dunlap <rdunlap@...radead.org>, Kees Cook <kees@...flux.net>,
	Peter Zijlstra <peterz@...radead.org>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	Puranjay Mohan <puranjay@...nel.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Jonathan Corbet <corbet@....net>, x86@...nel.org,
	linux-doc@...r.kernel.org, linux-kbuild@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-riscv@...ts.infradead.org, llvm@...ts.linux.dev,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH 5/5] kcfi: Rename CONFIG_CFI_CLANG to CONFIG_CFI

On Thu, Aug 28, 2025 at 04:32:16PM -0400, Kees Cook wrote:
> On August 28, 2025 4:19:15 PM EDT, Nathan Chancellor <nathan@...nel.org> wrote:
> >On Thu, Aug 28, 2025 at 02:11:51PM +0200, Miguel Ojeda wrote:
> >> On Wed, Aug 27, 2025 at 9:38 PM Nathan Chancellor <nathan@...nel.org> wrote:
> >> > 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.
> >> 
> >> If we are OK with something like this (i.e. waiting a few releases),
> >> then isn't it simpler the `def_bool` approach I mentioned? i.e. it
> >> means one less symbol and one less rename later, right?
> >
> >Ah yes, I reread your suggestion and that would probably be the best
> >course of action, as it does avoid the extra symbol (although I am not
> >sure what you mean by one less rename?). As I understand it:
> >
> >  config CFI_CLANG
> >      bool "Use Kernel Control Flow Integrity (kCFI)"
> >      depends on ARCH_SUPPORTS_CFI
> >      depends on $(cc-option,-fsanitize=kcfi)
> >      help
> >        <generic help text>
> >
> >  config CFI
> >      def_bool CFI_CLANG
> 
> Oh! Keep CFI_CLANG the visible option? Will the later rename work right? I'll give it a try.

It should, as long as people are at least upgrading LTS releases
continuously. In theory, there could be people who upgrade with a
configuration that has CONFIG_CFI_CLANG=y to a release after the rename
to CONFIG_CFI happens but at that point, I would expect them to need to
diff their configuration to make sure other items did not go missing or
change since they are going across many months/releases when upgrading.
I think doing it this way is a healthy balance of not breaking the
people who upgrade their kernels yearly (via LTS) or every stable
release while allowing the code as a whole to become more generic in the
meantime.

Folks who have CONFIG_CFI_CLANG=y in defconfigs like Android should
notice it disappearing and be able to figure out that it got renamed and
adjust, since they already have to do that for other symbols.

Cheers,
Nathan