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@xxxxxxxxxx> 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
then keep the rest of the change the same with the rename? I guess the
CLANG in the symbol name could be confusing for some people but thinking
about the timeline more, kCFI would not ship until GCC 16 in the spring
of 2026, which would be after the Linux LTS release at the end of 2025.
That means we could easily drop CONFIG_CFI_CLANG in the first release of
2026 so that compatible GCC users should only ever see CONFIG_CFI from
mainline. They could see CONFIG_CFI_CLANG in the LTS release but at
least it would work.
Cheers,
Nathan
