mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
[linux-2.6-microblaze.git] / security / Kconfig.hardening
index c6cb2d9..a1ffe2e 100644 (file)
@@ -160,6 +160,35 @@ config STACKLEAK_RUNTIME_DISABLE
          runtime to control kernel stack erasing for kernels built with
          CONFIG_GCC_PLUGIN_STACKLEAK.
 
+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