Merge remote-tracking branch 'torvalds/master' into perf/urgent
[linux-2.6-microblaze.git] / arch / Kconfig
index 2bb3067..c45b770 100644 (file)
@@ -631,14 +631,12 @@ config ARCH_SUPPORTS_LTO_CLANG_THIN
 config HAS_LTO_CLANG
        def_bool y
        # Clang >= 11: https://github.com/ClangBuiltLinux/linux/issues/510
-       depends on CC_IS_CLANG && CLANG_VERSION >= 110000 && LD_IS_LLD
-       depends on $(success,test $(LLVM) -eq 1)
-       depends on $(success,test $(LLVM_IAS) -eq 1)
+       depends on CC_IS_CLANG && CLANG_VERSION >= 110000 && LD_IS_LLD && AS_IS_LLVM
        depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
        depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
        depends on ARCH_SUPPORTS_LTO_CLANG
        depends on !FTRACE_MCOUNT_USE_RECORDMCOUNT
-       depends on !KASAN
+       depends on !KASAN || KASAN_HW_TAGS
        depends on !GCOV_KERNEL
        help
          The compiler and Kconfig options support building with Clang's
@@ -693,6 +691,51 @@ config LTO_CLANG_THIN
          If unsure, say Y.
 endchoice
 
+config ARCH_SUPPORTS_CFI_CLANG
+       bool
+       help
+         An architecture should select this option if it can support Clang's
+         Control-Flow Integrity (CFI) checking.
+
+config CFI_CLANG
+       bool "Use Clang's Control Flow Integrity (CFI)"
+       depends on LTO_CLANG && ARCH_SUPPORTS_CFI_CLANG
+       # Clang >= 12:
+       # - https://bugs.llvm.org/show_bug.cgi?id=46258
+       # - https://bugs.llvm.org/show_bug.cgi?id=47479
+       depends on CLANG_VERSION >= 120000
+       select KALLSYMS
+       help
+         This option enables Clang’s forward-edge Control Flow Integrity
+         (CFI) checking, where the compiler injects a runtime check to each
+         indirect function call to ensure the target is a valid function with
+         the correct static type. This restricts possible call targets and
+         makes it more difficult for an attacker to exploit bugs that allow
+         the modification of stored function pointers. More information can be
+         found from Clang's documentation:
+
+           https://clang.llvm.org/docs/ControlFlowIntegrity.html
+
+config CFI_CLANG_SHADOW
+       bool "Use CFI shadow to speed up cross-module checks"
+       default y
+       depends on CFI_CLANG && MODULES
+       help
+         If you select this option, the kernel builds a fast look-up table of
+         CFI check functions in loaded modules to reduce performance overhead.
+
+         If unsure, say Y.
+
+config CFI_PERMISSIVE
+       bool "Use CFI in permissive mode"
+       depends on CFI_CLANG
+       help
+         When selected, Control Flow Integrity (CFI) violations result in a
+         warning instead of a kernel panic. This option should only be used
+         for finding indirect call type mismatches during development.
+
+         If unsure, say N.
+
 config HAVE_ARCH_WITHIN_STACK_FRAMES
        bool
        help
@@ -786,6 +829,17 @@ config HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
 config HAVE_ARCH_HUGE_VMAP
        bool
 
+#
+#  Archs that select this would be capable of PMD-sized vmaps (i.e.,
+#  arch_vmap_pmd_supported() returns true), and they must make no assumptions
+#  that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag
+#  can be used to prohibit arch-specific allocations from using hugepages to
+#  help with this (e.g., modules may require it).
+#
+config HAVE_ARCH_HUGE_VMALLOC
+       depends on HAVE_ARCH_HUGE_VMAP
+       bool
+
 config ARCH_WANT_HUGE_PMD_SHARE
        bool
 
@@ -1014,6 +1068,13 @@ config COMPAT_32BIT_TIME
 config ARCH_NO_PREEMPT
        bool
 
+config ARCH_EPHEMERAL_INODES
+       def_bool n
+       help
+         An arch should select this symbol if it doesn't keep track of inode
+         instances on its own, but instead relies on something else (e.g. the
+         host kernel for an UML kernel).
+
 config ARCH_SUPPORTS_RT
        bool
 
@@ -1055,6 +1116,29 @@ config VMAP_STACK
          backing virtual mappings with real shadow memory, and KASAN_VMALLOC
          must be enabled.
 
+config HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
+       def_bool n
+       help
+         An arch should select this symbol if it can support kernel stack
+         offset randomization with calls to add_random_kstack_offset()
+         during syscall entry and choose_random_kstack_offset() during
+         syscall exit. Careful removal of -fstack-protector-strong and
+         -fstack-protector should also be applied to the entry code and
+         closely examined, as the artificial stack bump looks like an array
+         to the compiler, so it will attempt to add canary checks regardless
+         of the static branch state.
+
+config RANDOMIZE_KSTACK_OFFSET_DEFAULT
+       bool "Randomize kernel stack offset on syscall entry"
+       depends on HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
+       help
+         The kernel stack offset can be randomized (after pt_regs) by
+         roughly 5 bits of entropy, frustrating memory corruption
+         attacks that depend on stack address determinism or
+         cross-syscall address exposures. This feature is controlled
+         by kernel boot param "randomize_kstack_offset=on/off", and this
+         config chooses the default boot state.
+
 config ARCH_OPTIONAL_KERNEL_RWX
        def_bool n