On 8/27/25 12:38 PM, Nathan Chancellor wrote: > 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@xxxxxxxxx> wrote: >>>>> On Mon, Aug 25, 2025 at 5:35 PM Kees Cook <kees@xxxxxxxxxx> 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 OK, I don't know the state of the CFI_CLANG / CLANG patch(es). I just mean the difference in 'make oldconfig' and 'make olddefconfig' (at least AIUI). > 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 Yes, I agree. > Linus feels even as recently as this past merge window: > > https://lore.kernel.org/CAHk-=wgO0Rx2LcYT4f75Xs46orbJ4JxO2jbAFQnVKDYAjV5HeQ@xxxxxxxxxxxxxx/ > > 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. -- ~Randy
