fork: Add generic vmalloced stack support

[karo-tx-linux.git] / arch / Kconfig

diff --git a/arch/Kconfig b/arch/Kconfig
index e9734796531f022cd188411e1bb14450922b74ef..9ecf9f6f9e15b2093560311da73351958dc444a6 100644 (file)
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -226,8 +226,8 @@ config ARCH_INIT_TASK
 config ARCH_TASK_STRUCT_ALLOCATOR
        bool
 
-# Select if arch has its private alloc_thread_info() function
-config ARCH_THREAD_INFO_ALLOCATOR
+# Select if arch has its private alloc_thread_stack() function
+config ARCH_THREAD_STACK_ALLOCATOR
        bool
 
 # Select if arch wants to size task_struct dynamically via arch_task_struct_size:
@@ -357,6 +357,43 @@ config SECCOMP_FILTER
 
          See Documentation/prctl/seccomp_filter.txt for details.
 
+config HAVE_GCC_PLUGINS
+       bool
+       help
+         An arch should select this symbol if it supports building with
+         GCC plugins.
+
+menuconfig GCC_PLUGINS
+       bool "GCC plugins"
+       depends on HAVE_GCC_PLUGINS
+       depends on !COMPILE_TEST
+       help
+         GCC plugins are loadable modules that provide extra features to the
+         compiler. They are useful for runtime instrumentation and static analysis.
+
+         See Documentation/gcc-plugins.txt for details.
+
+config GCC_PLUGIN_CYC_COMPLEXITY
+       bool "Compute the cyclomatic complexity of a function"
+       depends on GCC_PLUGINS
+       help
+         The complexity M of a function's control flow graph is defined as:
+          M = E - N + 2P
+         where
+
+         E = the number of edges
+         N = the number of nodes
+         P = the number of connected components (exit nodes).
+
+config GCC_PLUGIN_SANCOV
+       bool
+       depends on GCC_PLUGINS
+       help
+         This plugin inserts a __sanitizer_cov_trace_pc() call at the start of
+         basic blocks. It supports all gcc versions with plugin support (from
+         gcc-4.5 on). It is based on the commit "Add fuzzing coverage support"
+         by Dmitry Vyukov <dvyukov@google.com>.
+
 config HAVE_CC_STACKPROTECTOR
        bool
        help
@@ -424,6 +461,15 @@ config CC_STACKPROTECTOR_STRONG
 
 endchoice
 
+config HAVE_ARCH_WITHIN_STACK_FRAMES
+       bool
+       help
+         An architecture should select this if it can walk the kernel stack
+         frames to determine if an object is part of either the arguments
+         or local variables (i.e. that it excludes saved return addresses,
+         and similar) by implementing an inline arch_within_stack_frames(),
+         which is used by CONFIG_HARDENED_USERCOPY.
+
 config HAVE_CONTEXT_TRACKING
        bool
        help
@@ -661,4 +707,38 @@ config ARCH_NO_COHERENT_DMA_MMAP
 config CPU_NO_EFFICIENT_FFS
        def_bool n
 
+config HAVE_ARCH_VMAP_STACK
+       def_bool n
+       help
+         An arch should select this symbol if it can support kernel stacks
+         in vmalloc space.  This means:
+
+         - vmalloc space must be large enough to hold many kernel stacks.
+           This may rule out many 32-bit architectures.
+
+         - Stacks in vmalloc space need to work reliably.  For example, if
+           vmap page tables are created on demand, either this mechanism
+           needs to work while the stack points to a virtual address with
+           unpopulated page tables or arch code (switch_to() and switch_mm(),
+           most likely) needs to ensure that the stack's page table entries
+           are populated before running on a possibly unpopulated stack.
+
+         - If the stack overflows into a guard page, something reasonable
+           should happen.  The definition of "reasonable" is flexible, but
+           instantly rebooting without logging anything would be unfriendly.
+
+config VMAP_STACK
+       default y
+       bool "Use a virtually-mapped stack"
+       depends on HAVE_ARCH_VMAP_STACK && !KASAN
+       ---help---
+         Enable this if you want the use virtually-mapped kernel stacks
+         with guard pages.  This causes kernel stack overflows to be
+         caught immediately rather than causing difficult-to-diagnose
+         corruption.
+
+         This is presently incompatible with KASAN because KASAN expects
+         the stack to map directly to the KASAN shadow map using a formula
+         that is incorrect if the stack is in vmalloc space.
+
 source "kernel/gcov/Kconfig"