xref: /linux/security/Kconfig.hardening (revision 8e736a2eeaf261213b4557778e015699da1e1c8c)
1ec8f24b7SThomas Gleixner# SPDX-License-Identifier: GPL-2.0-only
29f671e58SKees Cookmenu "Kernel hardening options"
39f671e58SKees Cook
49f671e58SKees Cookmenu "Memory initialization"
59f671e58SKees Cook
6f0fe00d4Sglider@google.comconfig CC_HAS_AUTO_VAR_INIT_PATTERN
7709a972eSKees Cook	def_bool $(cc-option,-ftrivial-auto-var-init=pattern)
8709a972eSKees Cook
9607e57c6SKees Cookconfig CC_HAS_AUTO_VAR_INIT_ZERO_BARE
10607e57c6SKees Cook	def_bool $(cc-option,-ftrivial-auto-var-init=zero)
11607e57c6SKees Cook
12607e57c6SKees Cookconfig CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
13607e57c6SKees Cook	# Clang 16 and later warn about using the -enable flag, but it
14607e57c6SKees Cook	# is required before then.
15f0fe00d4Sglider@google.com	def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang)
16607e57c6SKees Cook	depends on !CC_HAS_AUTO_VAR_INIT_ZERO_BARE
17607e57c6SKees Cook
18607e57c6SKees Cookconfig CC_HAS_AUTO_VAR_INIT_ZERO
19607e57c6SKees Cook	def_bool CC_HAS_AUTO_VAR_INIT_ZERO_BARE || CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
20f0fe00d4Sglider@google.com
219f671e58SKees Cookchoice
229f671e58SKees Cook	prompt "Initialize kernel stack variables at function entry"
23f0fe00d4Sglider@google.com	default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN
24f02003c8SKees Cook	default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO
259f671e58SKees Cook	default INIT_STACK_NONE
269f671e58SKees Cook	help
279f671e58SKees Cook	  This option enables initialization of stack variables at
289f671e58SKees Cook	  function entry time. This has the possibility to have the
299f671e58SKees Cook	  greatest coverage (since all functions can have their
309f671e58SKees Cook	  variables initialized), but the performance impact depends
319f671e58SKees Cook	  on the function calling complexity of a given workload's
329f671e58SKees Cook	  syscalls.
339f671e58SKees Cook
349f671e58SKees Cook	  This chooses the level of coverage over classes of potentially
35dcb7c0b9SKees Cook	  uninitialized variables. The selected class of variable will be
369f671e58SKees Cook	  initialized before use in a function.
379f671e58SKees Cook
389f671e58SKees Cook	config INIT_STACK_NONE
39dcb7c0b9SKees Cook		bool "no automatic stack variable initialization (weakest)"
409f671e58SKees Cook		help
419f671e58SKees Cook		  Disable automatic stack variable initialization.
429f671e58SKees Cook		  This leaves the kernel vulnerable to the standard
439f671e58SKees Cook		  classes of uninitialized stack variable exploits
449f671e58SKees Cook		  and information exposures.
459f671e58SKees Cook
46f0fe00d4Sglider@google.com	config INIT_STACK_ALL_PATTERN
47dcb7c0b9SKees Cook		bool "pattern-init everything (strongest)"
48f0fe00d4Sglider@google.com		depends on CC_HAS_AUTO_VAR_INIT_PATTERN
4942eaa27dSAlexander Potapenko		depends on !KMSAN
50709a972eSKees Cook		help
51dcb7c0b9SKees Cook		  Initializes everything on the stack (including padding)
52dcb7c0b9SKees Cook		  with a specific debug value. This is intended to eliminate
53dcb7c0b9SKees Cook		  all classes of uninitialized stack variable exploits and
54dcb7c0b9SKees Cook		  information exposures, even variables that were warned about
55dcb7c0b9SKees Cook		  having been left uninitialized.
56709a972eSKees Cook
57f0fe00d4Sglider@google.com		  Pattern initialization is known to provoke many existing bugs
58f0fe00d4Sglider@google.com		  related to uninitialized locals, e.g. pointers receive
59dcb7c0b9SKees Cook		  non-NULL values, buffer sizes and indices are very big. The
60dcb7c0b9SKees Cook		  pattern is situation-specific; Clang on 64-bit uses 0xAA
61dcb7c0b9SKees Cook		  repeating for all types and padding except float and double
62dcb7c0b9SKees Cook		  which use 0xFF repeating (-NaN). Clang on 32-bit uses 0xFF
63dcb7c0b9SKees Cook		  repeating for all types and padding.
64a9a5e0bdSGeert Uytterhoeven		  GCC uses 0xFE repeating for all types, and zero for padding.
65f0fe00d4Sglider@google.com
66f0fe00d4Sglider@google.com	config INIT_STACK_ALL_ZERO
67dcb7c0b9SKees Cook		bool "zero-init everything (strongest and safest)"
68f0fe00d4Sglider@google.com		depends on CC_HAS_AUTO_VAR_INIT_ZERO
6942eaa27dSAlexander Potapenko		depends on !KMSAN
70f0fe00d4Sglider@google.com		help
71dcb7c0b9SKees Cook		  Initializes everything on the stack (including padding)
72dcb7c0b9SKees Cook		  with a zero value. This is intended to eliminate all
73dcb7c0b9SKees Cook		  classes of uninitialized stack variable exploits and
74dcb7c0b9SKees Cook		  information exposures, even variables that were warned
75dcb7c0b9SKees Cook		  about having been left uninitialized.
76f0fe00d4Sglider@google.com
77dcb7c0b9SKees Cook		  Zero initialization provides safe defaults for strings
78dcb7c0b9SKees Cook		  (immediately NUL-terminated), pointers (NULL), indices
79dcb7c0b9SKees Cook		  (index 0), and sizes (0 length), so it is therefore more
80dcb7c0b9SKees Cook		  suitable as a production security mitigation than pattern
81dcb7c0b9SKees Cook		  initialization.
82f0fe00d4Sglider@google.com
839f671e58SKees Cookendchoice
849f671e58SKees Cook
85*a8f0b1f8SKees Cookconfig CC_HAS_SANCOV_STACK_DEPTH_CALLBACK
86*a8f0b1f8SKees Cook	def_bool $(cc-option,-fsanitize-coverage-stack-depth-callback-min=1)
87*a8f0b1f8SKees Cook
8857fbad15SKees Cookconfig KSTACK_ERASE
89b6a6a377SKees Cook	bool "Poison kernel stack before returning from syscalls"
9057fbad15SKees Cook	depends on HAVE_ARCH_KSTACK_ERASE
91*a8f0b1f8SKees Cook	depends on GCC_PLUGINS || CC_HAS_SANCOV_STACK_DEPTH_CALLBACK
92b6a6a377SKees Cook	help
93b6a6a377SKees Cook	  This option makes the kernel erase the kernel stack before
94b6a6a377SKees Cook	  returning from system calls. This has the effect of leaving
95b6a6a377SKees Cook	  the stack initialized to the poison value, which both reduces
96b6a6a377SKees Cook	  the lifetime of any sensitive stack contents and reduces
97b6a6a377SKees Cook	  potential for uninitialized stack variable exploits or information
98b6a6a377SKees Cook	  exposures (it does not cover functions reaching the same stack
99b6a6a377SKees Cook	  depth as prior functions during the same syscall). This blocks
100b6a6a377SKees Cook	  most uninitialized stack variable attacks, with the performance
101b6a6a377SKees Cook	  impact being driven by the depth of the stack usage, rather than
102b6a6a377SKees Cook	  the function calling complexity.
103b6a6a377SKees Cook
104b6a6a377SKees Cook	  The performance impact on a single CPU system kernel compilation
105b6a6a377SKees Cook	  sees a 1% slowdown, other systems and workloads may vary and you
106b6a6a377SKees Cook	  are advised to test this feature on your expected workload before
107b6a6a377SKees Cook	  deploying it.
108b6a6a377SKees Cook
10957fbad15SKees Cookconfig GCC_PLUGIN_STACKLEAK
11057fbad15SKees Cook	def_bool KSTACK_ERASE
11157fbad15SKees Cook	depends on GCC_PLUGINS
11257fbad15SKees Cook	help
113b6a6a377SKees Cook	  This plugin was ported from grsecurity/PaX. More information at:
114b6a6a377SKees Cook	   * https://grsecurity.net/
115b6a6a377SKees Cook	   * https://pax.grsecurity.net/
116b6a6a377SKees Cook
117f154066bSKees Cookconfig GCC_PLUGIN_STACKLEAK_VERBOSE
118f154066bSKees Cook	bool "Report stack depth analysis instrumentation" if EXPERT
119f154066bSKees Cook	depends on GCC_PLUGIN_STACKLEAK
120f154066bSKees Cook	depends on !COMPILE_TEST	# too noisy
121f154066bSKees Cook	help
122f154066bSKees Cook	  This option will cause a warning to be printed each time the
123f154066bSKees Cook	  stackleak plugin finds a function it thinks needs to be
124f154066bSKees Cook	  instrumented. This is useful for comparing coverage between
125f154066bSKees Cook	  builds.
126f154066bSKees Cook
12757fbad15SKees Cookconfig KSTACK_ERASE_TRACK_MIN_SIZE
12857fbad15SKees Cook	int "Minimum stack frame size of functions tracked by KSTACK_ERASE"
129b6a6a377SKees Cook	default 100
130b6a6a377SKees Cook	range 0 4096
13157fbad15SKees Cook	depends on KSTACK_ERASE
132b6a6a377SKees Cook	help
13357fbad15SKees Cook	  The KSTACK_ERASE option instruments the kernel code for tracking
134b6a6a377SKees Cook	  the lowest border of the kernel stack (and for some other purposes).
1359ea1e8d2SKees Cook	  It inserts the __sanitizer_cov_stack_depth() call for the functions
1369ea1e8d2SKees Cook	  with a stack frame size greater than or equal to this parameter.
137b6a6a377SKees Cook	  If unsure, leave the default value 100.
138b6a6a377SKees Cook
13957fbad15SKees Cookconfig KSTACK_ERASE_METRICS
14057fbad15SKees Cook	bool "Show KSTACK_ERASE metrics in the /proc file system"
14157fbad15SKees Cook	depends on KSTACK_ERASE
142b6a6a377SKees Cook	depends on PROC_FS
143b6a6a377SKees Cook	help
14457fbad15SKees Cook	  If this is set, KSTACK_ERASE metrics for every task are available
14557fbad15SKees Cook	  in the /proc file system. In particular, /proc/<pid>/stack_depth
146b6a6a377SKees Cook	  shows the maximum kernel stack consumption for the current and
147b6a6a377SKees Cook	  previous syscalls. Although this information is not precise, it
14857fbad15SKees Cook	  can be useful for estimating the KSTACK_ERASE performance impact
14957fbad15SKees Cook	  for your workloads.
150b6a6a377SKees Cook
15157fbad15SKees Cookconfig KSTACK_ERASE_RUNTIME_DISABLE
152b6a6a377SKees Cook	bool "Allow runtime disabling of kernel stack erasing"
15357fbad15SKees Cook	depends on KSTACK_ERASE
154b6a6a377SKees Cook	help
155b6a6a377SKees Cook	  This option provides 'stack_erasing' sysctl, which can be used in
156b6a6a377SKees Cook	  runtime to control kernel stack erasing for kernels built with
15757fbad15SKees Cook	  CONFIG_KSTACK_ERASE.
158b6a6a377SKees Cook
1596471384aSAlexander Potapenkoconfig INIT_ON_ALLOC_DEFAULT_ON
1606471384aSAlexander Potapenko	bool "Enable heap memory zeroing on allocation by default"
16142eaa27dSAlexander Potapenko	depends on !KMSAN
1626471384aSAlexander Potapenko	help
1636471384aSAlexander Potapenko	  This has the effect of setting "init_on_alloc=1" on the kernel
1646471384aSAlexander Potapenko	  command line. This can be disabled with "init_on_alloc=0".
1656471384aSAlexander Potapenko	  When "init_on_alloc" is enabled, all page allocator and slab
1666471384aSAlexander Potapenko	  allocator memory will be zeroed when allocated, eliminating
1676471384aSAlexander Potapenko	  many kinds of "uninitialized heap memory" flaws, especially
1686471384aSAlexander Potapenko	  heap content exposures. The performance impact varies by
1696471384aSAlexander Potapenko	  workload, but most cases see <1% impact. Some synthetic
1706471384aSAlexander Potapenko	  workloads have measured as high as 7%.
1716471384aSAlexander Potapenko
1726471384aSAlexander Potapenkoconfig INIT_ON_FREE_DEFAULT_ON
1736471384aSAlexander Potapenko	bool "Enable heap memory zeroing on free by default"
17442eaa27dSAlexander Potapenko	depends on !KMSAN
1756471384aSAlexander Potapenko	help
1766471384aSAlexander Potapenko	  This has the effect of setting "init_on_free=1" on the kernel
1776471384aSAlexander Potapenko	  command line. This can be disabled with "init_on_free=0".
1786471384aSAlexander Potapenko	  Similar to "init_on_alloc", when "init_on_free" is enabled,
1796471384aSAlexander Potapenko	  all page allocator and slab allocator memory will be zeroed
1806471384aSAlexander Potapenko	  when freed, eliminating many kinds of "uninitialized heap memory"
1816471384aSAlexander Potapenko	  flaws, especially heap content exposures. The primary difference
1826471384aSAlexander Potapenko	  with "init_on_free" is that data lifetime in memory is reduced,
1836471384aSAlexander Potapenko	  as anything freed is wiped immediately, making live forensics or
1846471384aSAlexander Potapenko	  cold boot memory attacks unable to recover freed memory contents.
1856471384aSAlexander Potapenko	  The performance impact varies by workload, but is more expensive
1866471384aSAlexander Potapenko	  than "init_on_alloc" due to the negative cache effects of
1876471384aSAlexander Potapenko	  touching "cold" memory areas. Most cases see 3-5% impact. Some
1886471384aSAlexander Potapenko	  synthetic workloads have measured as high as 8%.
1896471384aSAlexander Potapenko
190a82adfd5SKees Cookconfig CC_HAS_ZERO_CALL_USED_REGS
191a82adfd5SKees Cook	def_bool $(cc-option,-fzero-call-used-regs=used-gpr)
192d6a9fb87SNathan Chancellor	# https://github.com/ClangBuiltLinux/linux/issues/1766
193d6a9fb87SNathan Chancellor	# https://github.com/llvm/llvm-project/issues/59242
194d6a9fb87SNathan Chancellor	depends on !CC_IS_CLANG || CLANG_VERSION > 150006
195a82adfd5SKees Cook
196a82adfd5SKees Cookconfig ZERO_CALL_USED_REGS
197a82adfd5SKees Cook	bool "Enable register zeroing on function exit"
198a82adfd5SKees Cook	depends on CC_HAS_ZERO_CALL_USED_REGS
199a82adfd5SKees Cook	help
200a82adfd5SKees Cook	  At the end of functions, always zero any caller-used register
201a82adfd5SKees Cook	  contents. This helps ensure that temporary values are not
202a82adfd5SKees Cook	  leaked beyond the function boundary. This means that register
203a82adfd5SKees Cook	  contents are less likely to be available for side channels
204a82adfd5SKees Cook	  and information exposures. Additionally, this helps reduce the
205a82adfd5SKees Cook	  number of useful ROP gadgets by about 20% (and removes compiler
206a82adfd5SKees Cook	  generated "write-what-where" gadgets) in the resulting kernel
207a82adfd5SKees Cook	  image. This has a less than 1% performance impact on most
208a82adfd5SKees Cook	  workloads. Image size growth depends on architecture, and should
209a82adfd5SKees Cook	  be evaluated for suitability. For example, x86_64 grows by less
210a82adfd5SKees Cook	  than 1%, and arm64 grows by about 5%.
211a82adfd5SKees Cook
2129f671e58SKees Cookendmenu
2139f671e58SKees Cook
214f4d4e8b9SMel Gormanmenu "Bounds checking"
215f4d4e8b9SMel Gorman
216ca758b14SMel Gormanconfig FORTIFY_SOURCE
217ca758b14SMel Gorman	bool "Harden common str/mem functions against buffer overflows"
218ca758b14SMel Gorman	depends on ARCH_HAS_FORTIFY_SOURCE
219ca758b14SMel Gorman	# https://github.com/llvm/llvm-project/issues/53645
220d70da124SKees Cook	depends on !X86_32 || !CC_IS_CLANG || CLANG_VERSION >= 160000
221ca758b14SMel Gorman	help
222ca758b14SMel Gorman	  Detect overflows of buffers in common string and memory functions
223ca758b14SMel Gorman	  where the compiler can determine and validate the buffer sizes.
224ca758b14SMel Gorman
225f4d4e8b9SMel Gormanconfig HARDENED_USERCOPY
226f4d4e8b9SMel Gorman	bool "Harden memory copies between kernel and userspace"
227f4d4e8b9SMel Gorman	imply STRICT_DEVMEM
228f4d4e8b9SMel Gorman	help
229f4d4e8b9SMel Gorman	  This option checks for obviously wrong memory regions when
230f4d4e8b9SMel Gorman	  copying memory to/from the kernel (via copy_to_user() and
231f4d4e8b9SMel Gorman	  copy_from_user() functions) by rejecting memory ranges that
232f4d4e8b9SMel Gorman	  are larger than the specified heap object, span multiple
233f4d4e8b9SMel Gorman	  separately allocated pages, are not on the process stack,
234f4d4e8b9SMel Gorman	  or are part of the kernel text. This prevents entire classes
235f4d4e8b9SMel Gorman	  of heap overflow exploits and similar kernel memory exposures.
236f4d4e8b9SMel Gorman
237d2132f45SMel Gormanconfig HARDENED_USERCOPY_DEFAULT_ON
238d2132f45SMel Gorman	bool "Harden memory copies by default"
239d2132f45SMel Gorman	depends on HARDENED_USERCOPY
240d2132f45SMel Gorman	default HARDENED_USERCOPY
241d2132f45SMel Gorman	help
242d2132f45SMel Gorman	  This has the effect of setting "hardened_usercopy=on" on the kernel
243d2132f45SMel Gorman	  command line. This can be disabled with "hardened_usercopy=off".
244d2132f45SMel Gorman
245f4d4e8b9SMel Gormanendmenu
246f4d4e8b9SMel Gorman
247aebc7b0dSMarco Elvermenu "Hardening of kernel data structures"
248aebc7b0dSMarco Elver
249aebc7b0dSMarco Elverconfig LIST_HARDENED
250aebc7b0dSMarco Elver	bool "Check integrity of linked list manipulation"
251aebc7b0dSMarco Elver	help
252aebc7b0dSMarco Elver	  Minimal integrity checking in the linked-list manipulation routines
253aebc7b0dSMarco Elver	  to catch memory corruptions that are not guaranteed to result in an
254aebc7b0dSMarco Elver	  immediate access fault.
255aebc7b0dSMarco Elver
256aebc7b0dSMarco Elver	  If unsure, say N.
257aebc7b0dSMarco Elver
258aa9f10d5SMarco Elverconfig BUG_ON_DATA_CORRUPTION
259aa9f10d5SMarco Elver	bool "Trigger a BUG when data corruption is detected"
260aa9f10d5SMarco Elver	select LIST_HARDENED
261aa9f10d5SMarco Elver	help
262aa9f10d5SMarco Elver	  Select this option if the kernel should BUG when it encounters
263aa9f10d5SMarco Elver	  data corruption in kernel memory structures when they get checked
264aa9f10d5SMarco Elver	  for validity.
265aa9f10d5SMarco Elver
266aa9f10d5SMarco Elver	  If unsure, say N.
267aa9f10d5SMarco Elver
268aebc7b0dSMarco Elverendmenu
269aebc7b0dSMarco Elver
270035f7f87SKees Cookconfig CC_HAS_RANDSTRUCT
271035f7f87SKees Cook	def_bool $(cc-option,-frandomize-layout-seed-file=/dev/null)
27278f7a3fdSEric Biggers	# Randstruct was first added in Clang 15, but it isn't safe to use until
27378f7a3fdSEric Biggers	# Clang 16 due to https://github.com/llvm/llvm-project/issues/60349
27478f7a3fdSEric Biggers	depends on !CC_IS_CLANG || CLANG_VERSION >= 160000
275035f7f87SKees Cook
276595b893eSKees Cookchoice
277595b893eSKees Cook	prompt "Randomize layout of sensitive kernel structures"
278f0cd6012SKees Cook	default RANDSTRUCT_FULL if COMPILE_TEST && (GCC_PLUGINS || CC_HAS_RANDSTRUCT)
279595b893eSKees Cook	default RANDSTRUCT_NONE
280595b893eSKees Cook	help
281595b893eSKees Cook	  If you enable this, the layouts of structures that are entirely
282595b893eSKees Cook	  function pointers (and have not been manually annotated with
283595b893eSKees Cook	  __no_randomize_layout), or structures that have been explicitly
284595b893eSKees Cook	  marked with __randomize_layout, will be randomized at compile-time.
285595b893eSKees Cook	  This can introduce the requirement of an additional information
286595b893eSKees Cook	  exposure vulnerability for exploits targeting these structure
287595b893eSKees Cook	  types.
288595b893eSKees Cook
289595b893eSKees Cook	  Enabling this feature will introduce some performance impact,
290595b893eSKees Cook	  slightly increase memory usage, and prevent the use of forensic
291595b893eSKees Cook	  tools like Volatility against the system (unless the kernel
292595b893eSKees Cook	  source tree isn't cleaned after kernel installation).
293595b893eSKees Cook
294be2b34faSKees Cook	  The seed used for compilation is in scripts/basic/randomize.seed.
295be2b34faSKees Cook	  It remains after a "make clean" to allow for external modules to
296be2b34faSKees Cook	  be compiled with the existing seed and will be removed by a
297be2b34faSKees Cook	  "make mrproper" or "make distclean". This file should not be made
298be2b34faSKees Cook	  public, or the structure layout can be determined.
299595b893eSKees Cook
300595b893eSKees Cook	config RANDSTRUCT_NONE
301595b893eSKees Cook		bool "Disable structure layout randomization"
302595b893eSKees Cook		help
303595b893eSKees Cook		  Build normally: no structure layout randomization.
304595b893eSKees Cook
305595b893eSKees Cook	config RANDSTRUCT_FULL
306595b893eSKees Cook		bool "Fully randomize structure layout"
307035f7f87SKees Cook		depends on CC_HAS_RANDSTRUCT || GCC_PLUGINS
308dd3a7ee9SNathan Chancellor		select MODVERSIONS if MODULES && !COMPILE_TEST
309595b893eSKees Cook		help
310595b893eSKees Cook		  Fully randomize the member layout of sensitive
311595b893eSKees Cook		  structures as much as possible, which may have both a
312595b893eSKees Cook		  memory size and performance impact.
313595b893eSKees Cook
314035f7f87SKees Cook		  One difference between the Clang and GCC plugin
315035f7f87SKees Cook		  implementations is the handling of bitfields. The GCC
316035f7f87SKees Cook		  plugin treats them as fully separate variables,
317035f7f87SKees Cook		  introducing sometimes significant padding. Clang tries
318035f7f87SKees Cook		  to keep adjacent bitfields together, but with their bit
319035f7f87SKees Cook		  ordering randomized.
320035f7f87SKees Cook
321595b893eSKees Cook	config RANDSTRUCT_PERFORMANCE
322595b893eSKees Cook		bool "Limit randomization of structure layout to cache-lines"
323595b893eSKees Cook		depends on GCC_PLUGINS
324dd3a7ee9SNathan Chancellor		select MODVERSIONS if MODULES && !COMPILE_TEST
325595b893eSKees Cook		help
326595b893eSKees Cook		  Randomization of sensitive kernel structures will make a
327595b893eSKees Cook		  best effort at restricting randomization to cacheline-sized
328595b893eSKees Cook		  groups of members. It will further not randomize bitfields
329595b893eSKees Cook		  in structures. This reduces the performance hit of RANDSTRUCT
330595b893eSKees Cook		  at the cost of weakened randomization.
331595b893eSKees Cookendchoice
332595b893eSKees Cook
333595b893eSKees Cookconfig RANDSTRUCT
334595b893eSKees Cook	def_bool !RANDSTRUCT_NONE
335595b893eSKees Cook
336595b893eSKees Cookconfig GCC_PLUGIN_RANDSTRUCT
337595b893eSKees Cook	def_bool GCC_PLUGINS && RANDSTRUCT
338595b893eSKees Cook	help
339595b893eSKees Cook	  Use GCC plugin to randomize structure layout.
340595b893eSKees Cook
341595b893eSKees Cook	  This plugin was ported from grsecurity/PaX. More
342595b893eSKees Cook	  information at:
343595b893eSKees Cook	   * https://grsecurity.net/
344595b893eSKees Cook	   * https://pax.grsecurity.net/
345595b893eSKees Cook
3469f671e58SKees Cookendmenu
347