hc
2023-10-25 6c2073b7aa40e29d0eca7d571dd7bc590c7ecaa7
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
# SPDX-License-Identifier: GPL-2.0-only
menu "Kernel hardening options"
 
config GCC_PLUGIN_STRUCTLEAK
   bool
   help
     While the kernel is built with warnings enabled for any missed
     stack variable initializations, this warning is silenced for
     anything passed by reference to another function, under the
     occasionally misguided assumption that the function will do
     the initialization. As this regularly leads to exploitable
     flaws, this plugin is available to identify and zero-initialize
     such variables, depending on the chosen level of coverage.
 
     This plugin was originally ported from grsecurity/PaX. More
     information at:
      * https://grsecurity.net/
      * https://pax.grsecurity.net/
 
menu "Memory initialization"
 
config CC_HAS_AUTO_VAR_INIT_PATTERN
   def_bool $(cc-option,-ftrivial-auto-var-init=pattern)
 
config CC_HAS_AUTO_VAR_INIT_ZERO
   def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang)
 
choice
   prompt "Initialize kernel stack variables at function entry"
   default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS
   default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN
   default INIT_STACK_NONE
   help
     This option enables initialization of stack variables at
     function entry time. This has the possibility to have the
     greatest coverage (since all functions can have their
     variables initialized), but the performance impact depends
     on the function calling complexity of a given workload's
     syscalls.
 
     This chooses the level of coverage over classes of potentially
     uninitialized variables. The selected class will be
     initialized before use in a function.
 
   config INIT_STACK_NONE
       bool "no automatic initialization (weakest)"
       help
         Disable automatic stack variable initialization.
         This leaves the kernel vulnerable to the standard
         classes of uninitialized stack variable exploits
         and information exposures.
 
   config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
       bool "zero-init anything passed by reference (very strong)"
       depends on GCC_PLUGINS
       select GCC_PLUGIN_STRUCTLEAK
       help
         Zero-initialize any stack variables that may be passed
         by reference and had not already been explicitly
         initialized. This is intended to eliminate all classes
         of uninitialized stack variable exploits and information
         exposures.
 
   config INIT_STACK_ALL_PATTERN
       bool "0xAA-init everything on the stack (strongest)"
       depends on CC_HAS_AUTO_VAR_INIT_PATTERN
       help
         Initializes everything on the stack with a 0xAA
         pattern. This is intended to eliminate all classes
         of uninitialized stack variable exploits and information
         exposures, even variables that were warned to have been
         left uninitialized.
 
         Pattern initialization is known to provoke many existing bugs
         related to uninitialized locals, e.g. pointers receive
         non-NULL values, buffer sizes and indices are very big.
 
   config INIT_STACK_ALL_ZERO
       bool "zero-init everything on the stack (strongest and safest)"
       depends on CC_HAS_AUTO_VAR_INIT_ZERO
       help
         Initializes everything on the stack with a zero
         value. This is intended to eliminate all classes
         of uninitialized stack variable exploits and information
         exposures, even variables that were warned to have been
         left uninitialized.
 
         Zero initialization provides safe defaults for strings,
         pointers, indices and sizes, and is therefore
         more suitable as a security mitigation measure.
 
endchoice
 
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
   bool "Report forcefully initialized variables"
   depends on GCC_PLUGIN_STRUCTLEAK
   depends on !COMPILE_TEST    # too noisy
   help
     This option will cause a warning to be printed each time the
     structleak plugin finds a variable it thinks needs to be
     initialized. Since not all existing initializers are detected
     by the plugin, this can produce false positive warnings.
 
config INIT_ON_ALLOC_DEFAULT_ON
   bool "Enable heap memory zeroing on allocation by default"
   help
     This has the effect of setting "init_on_alloc=1" on the kernel
     command line. This can be disabled with "init_on_alloc=0".
     When "init_on_alloc" is enabled, all page allocator and slab
     allocator memory will be zeroed when allocated, eliminating
     many kinds of "uninitialized heap memory" flaws, especially
     heap content exposures. The performance impact varies by
     workload, but most cases see <1% impact. Some synthetic
     workloads have measured as high as 7%.
 
config INIT_ON_FREE_DEFAULT_ON
   bool "Enable heap memory zeroing on free by default"
   help
     This has the effect of setting "init_on_free=1" on the kernel
     command line. This can be disabled with "init_on_free=0".
     Similar to "init_on_alloc", when "init_on_free" is enabled,
     all page allocator and slab allocator memory will be zeroed
     when freed, eliminating many kinds of "uninitialized heap memory"
     flaws, especially heap content exposures. The primary difference
     with "init_on_free" is that data lifetime in memory is reduced,
     as anything freed is wiped immediately, making live forensics or
     cold boot memory attacks unable to recover freed memory contents.
     The performance impact varies by workload, but is more expensive
     than "init_on_alloc" due to the negative cache effects of
     touching "cold" memory areas. Most cases see 3-5% impact. Some
     synthetic workloads have measured as high as 8%.
 
endmenu
 
endmenu