Re: [RFC] kconfig: add hardened defconfig helpers

Re: [RFC] kconfig: add hardened defconfig helpers

[Kees Cook]

+lkml, Masahiro, and linux-doc, just for wider review/thoughts.

On Wed, Jul 18, 2018 at 10:38 AM, Salvatore Mesoraca
<s.mesoraca16@gmail.com> wrote:
> Adds 4 new defconfig helpers (hardenedlowconfig,
> hardenedmediumconfig, hardenedhighconfig,
> hardenedextremeconfig) to enable various hardening
> features.
> The list of config options to enable is based on
> KSPP's Recommended Settings[1] and on
> kconfig-hardened-check[2], with some modifications.
> These options are divided into 4 levels (low, medium,
> high, extreme) based on their negative side effects, not
> on their usefulness.
> 'Low' level collects all those protections that have
> (almost) no negative side effects.

Likely the "Low" should be on-by-default already, but it's easier to
bike-shed that separately. :)

> 'Extreme' level collects those protections that may have
> some many negative side effects that most people
> wouldn't want to enable them.
> Every feature in each level is briefly documented in
> Documentation/security/hardenedconfig.rst, this file
> also contain a better explanation of what every level
> means.
> To prevent this file from drifting from what the various
> defconfigs actually do, it is used to dynamically
> generate the config fragments.

I like that the configs are generated from the docs! This makes things
very sane to update.

>
> [1] http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
> [2] https://github.com/a13xp0p0v/kconfig-hardened-check
>
> Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
> ---
>  .gitignore                                 |    6 +
>  Documentation/security/hardenedconfig.rst  | 1027 ++++++++++++++++++++++++++++
>  Documentation/security/index.rst           |    1 +
>  Makefile                                   |    6 +-
>  scripts/kconfig/Makefile                   |   72 +-
>  scripts/kconfig/build_hardened_fragment.sh |   54 ++
>  6 files changed, 1143 insertions(+), 23 deletions(-)
>  create mode 100644 Documentation/security/hardenedconfig.rst
>  create mode 100755 scripts/kconfig/build_hardened_fragment.sh
>
> diff --git a/.gitignore b/.gitignore
> index 97ba6b7..9141f85 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -132,3 +132,9 @@ all.config
>
>  # Kdevelop4
>  *.kdev4
> +
> +# Generated config fragments
> +kernel/configs/hardenedlow.config
> +kernel/configs/hardenedmedium.config
> +kernel/configs/hardenedhigh.config
> +kernel/configs/hardenedextreme.config

I wonder if there should be an explicit "generated/" subdirectory in
kernel/configs/ ?

> diff --git a/Documentation/security/hardenedconfig.rst b/Documentation/security/hardenedconfig.rst
> new file mode 100644
> index 0000000..04ae0d9
> --- /dev/null
> +++ b/Documentation/security/hardenedconfig.rst

And thank you for doing this in .rst!

> @@ -0,0 +1,1027 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===============================
> +Hardening Configuration Options
> +===============================
> +
> +This is a list of configuration options that are useful for hardening purposes.
> +These options are divided in 4 levels based on the magnitude of their negative
> +side effects, not on their importance or usefulness:
> +
> +       - **Low**: Negligible performance impact. No user-space breakage.
> +       - **Medium**: Some performance impact and/or user-space breakage for
> +         few users.
> +       - **High**: Notable performance impact and/or user-space breakage for
> +         many users.
> +       - **Extreme**: Big performance impact and/or user-space breakage for
> +         most users.
> +
> +In other words: **Low** level contains protections that *everybody* can and
> +should use; **Medium** level should be usable by *most people* without issues;
> +**High** level may cause *some trouble*, especially from a *performance*
> +perspective; **Extreme** level contains protections that *few people* may want
> +to enable, some people will probably *cherry-pick* some options from here based
> +on their needs.
> +
> +For further details about which option is included in each level, please read
> +the description below, for more information on any particular option refer to
> +their help page.
> +
> +The content of this list is automatically translated into *config fragments*
> +that can be used to apply the suggested hardening options to your current
> +configuration.
> +To use them you just need to run ``make hardened$LEVELconfig`` (e.g.
> +``make hardenedhighconfig``).
> +
> +
> +
> +CONFIG_ACPI_CUSTOM_METHOD=n
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Self-protection

Rather than "self-protection", this is really about blocking direct
kernel memory writing from userspace. Maybe "Kernel memory integrity"?

> +
> +This debug facility allows ACPI AML methods to be inserted and/or replaced
> +without rebooting the system.
> +This option is security sensitive, because it allows arbitrary kernel
> +memory to be written to by root (uid=0) users, allowing them to bypass
> +certain security measures (e.g. if root is not allowed to load additional
> +kernel modules after boot, this feature may be used to override that
> +restriction).
> +
> +
> +CONFIG_BPF_JIT=n
> +~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** Attack surface reduction

This maybe should be clarified to "Kernel attack surface reduction"?

> +
> +Berkeley Packet Filter filtering capabilities are normally handled
> +by an interpreter. This option allows kernel to generate a native
> +code when filter is loaded in memory. This should speedup
> +packet sniffing (libpcap/tcpdump).
> +
> +Note, admin should enable this feature changing:
> +/proc/sys/net/core/bpf_jit_enable
> +/proc/sys/net/core/bpf_jit_harden   (optional)
> +/proc/sys/net/core/bpf_jit_kallsyms (optional)
> +
> +
> +CONFIG_BPF_SYSCALL=n
> +~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Attack surface reduction

Same.

> +
> +Enable the bpf() system call that allows to manipulate eBPF
> +programs and maps via file descriptors.
> +
> +
> +CONFIG_BUG=y
> +~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection

This was a left-over mistaken prerequisite for hardened-usercopy.
Without CONFIG_BUG, things will still stop kernel thread execution.
It's just much less pretty. :P Perhaps, if kept, this should be listed
as "Improved crash analysis" or "prerequisite"?

> +
> +Report BUG() conditions and kill the offending process.
> +There are very few cases in which this won't be desirable.
> +
> +
> +CONFIG_BUG_ON_DATA_CORRUPTION=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** Self-protection
> +
> +Select this option if the kernel should BUG when it encounters
> +data corruption in kernel memory structures when they get checked
> +for validity.
> +
> +
> +CONFIG_CC_STACKPROTECTOR=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Self-protection

"probabilistic kernel stack buffer overflow detection"?

There are a lot of "buffer overflow detection" things, so naming which
is which seems helpful, but is maybe overkill? "Self-protection" or
"kernel memory integrity" covers it too... hmmm

> +
> +Turns on the "stack-protector" GCC feature. This feature puts,
> +at the beginning of functions, a canary value on
> +the stack just before the return address, and validates
> +the value just before actually returning.  Stack based buffer
> +overflows (that need to overwrite this return address) now also
> +overwrite the canary, which gets detected and the attack is then
> +neutralized via a kernel panic.
> +
> +
> +CONFIG_CC_STACKPROTECTOR_STRONG=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Self-protection
> +
> +Functions will have the stack-protector canary logic added in any
> +of the following conditions:
> +
> +- local variable's address used as part of the right hand side of an
> +assignment or function argument
> +- local variable is an array (or union containing an array),
> +regardless of array type or length
> +- uses register local variables
> +
> +This feature requires gcc version 4.9 or above, or a distribution
> +gcc with the feature backported ("-fstack-protector-strong").
> +
> +On an x86 "defconfig" build, this feature adds canary checks to
> +about 20% of all kernel functions, which increases the kernel code
> +size by about 2%.

bikeshed: I think both stack protector items should be "Low", but
that's just me.

> +
> +
> +CONFIG_COMPAT_BRK=n
> +~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection

This is a userspace defense. "Userspace brk ASLR"?

> +
> +Randomizing heap placement makes heap exploits harder, but it
> +also breaks ancient binaries (including anything libc5 based).
> +This option changes the bootup default to heap randomization
> +disabled, and can be overridden at runtime by setting
> +/proc/sys/kernel/randomize_va_space to 2.
> +
> +On non-ancient distros (post-2000 ones) N is usually a safe choice.
> +
> +
> +CONFIG_COMPAT_VDSO=n
> +~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** User space protection
> +
> +
> +Map the VDSO to the predictable old-style address too.
> +Glibc 2.3.3 is the only version that needs it, but
> +OpenSUSE 9 contains a buggy "glibc 2.3.2".
> +
> +
> +CONFIG_DEBUG_CREDENTIALS=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Self-protection
> +
> +Turn on some debug checking for credential management.
> +These structs are often abused by attackers.
> +
> +
> +CONFIG_DEBUG_LIST=y
> +~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium

bikeshed: Low

> +**- Protection type:** Self-protection
> +
> +Turn on extended checks in the linked-list walking routines.
> +These structs are often abused by attackers.
> +
> +
> +CONFIG_DEBUG_NOTIFIERS=y
> +~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Self-protection
> +
> +Turn on sanity checking for notifier call chains.
> +These structs are often abused by attackers.
> +
> +
> +CONFIG_DEBUG_SG=y
> +~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Self-protection
> +
> +Turn on checks on scatter-gather tables.
> +These structs could be abused by attackers.
> +
> +
> +CONFIG_DEBUG_WX=y
> +~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +Generate a warning if any W+X mappings are found at boot.
> +This is useful for discovering cases where the kernel is leaving W+X
> +mappings after applying NX, as such mappings are a security risk.
> +There is no runtime or memory usage effect of this option once the
> +kernel has booted up - it's a one time check.
> +
> +
> +CONFIG_DEFAULT_MMAP_MIN_ADDR=65536

This is, unfortunately, architecture-specific. I'm not sure the best
way to deal with that with the make target...

> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +This is the portion of low virtual memory which should be protected
> +from userspace allocation.  Keeping a user from writing to low pages
> +can help reduce the impact of kernel NULL pointer bugs.
> +
> +This value can be changed after boot using the
> +/proc/sys/vm/mmap_min_addr tunable.
> +
> +
> +CONFIG_DEVKMEM=n
> +~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +The /dev/kmem device can be used by root to access kernel virtual memory.
> +It is rarely used, but can be used for certain kind of kernel debugging
> +operations.
> +
> +
> +CONFIG_DEVMEM=n
> +~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme

Why is this extreme?

> +**- Protection type:** Self-protection
> +
> +The /dev/mem device is used to access areas of physical
> +memory.
> +
> +
> +CONFIG_FORTIFY_SOURCE=y
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +Detect overflows of buffers in common string and memory functions
> +where the compiler can determine and validate the buffer sizes.
> +
> +
> +CONFIG_FTRACE=n
> +~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Self-protection

bikeshed: Kernel attack surface reduction

> +
> +Enable the kernel tracing infrastructure.
> +
> +
> +CONFIG_GCC_PLUGINS=y
> +~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection

"prerequisite"

> +
> +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_LATENT_ENTROPY=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** Self-protection
> +
> +With this pluging, the kernel will instrument some kernel code to
> +extract some entropy from both original and artificially created
> +program state. This will help especially embedded systems where
> +there is little 'natural' source of entropy normally.  The cost
> +is some slowdown of the boot process (about 0.5%) and fork and

This doesn't feel like "high" to me.

> +irq processing.
> +Note that entropy extracted this way is not cryptographically
> +secure!
> +
> +
> +CONFIG_GCC_PLUGIN_RANDSTRUCT=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium

This should surely be High or Extreme. It creates (nondeterministic)
performance impact and makes crashes undebuggable.

> +**- Protection type:** Self-protection
> +
> +With this pluging, the layouts of structures that are entirely
> +function pointers (and have not been manually annotated with
> +__no_randomize_layout), or structures that have been explicitly
> +marked with __randomize_layout, will be randomized at compile-time.
> +This can introduce the requirement of an additional information
> +exposure vulnerability for exploits targeting these structure
> +types.
> +Enabling this feature will introduce some performance impact,
> +slightly increase memory usage, and prevent the use of forensic
> +tools like Volatility against the system (unless the kernel
> +source tree isn't cleaned after kernel installation).
> +
> +
> +CONFIG_GCC_PLUGIN_STRUCTLEAK=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium

bikeshed: Low

> +**- Protection type:** Self-protection
> +
> +This plugin zero-initializes any structures containing a
> +__user attribute. This can prevent some classes of information
> +exposures.
> +
> +
> +CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Self-protection
> +
> +Zero initialize any struct type local variable that may be passed by
> +reference without having been initialized.
> +
> +
> +CONFIG_HARDENED_USERCOPY=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High

bikeshed: Low (all distros have this enabled already)

> +**- Protection type:** Self-protection
> +
> +This option checks for obviously wrong memory regions when
> +copying memory to/from the kernel (via copy_to_user() and
> +copy_from_user() functions) by rejecting memory ranges that
> +are larger than the specified heap object, span multiple
> +separately allocated pages, are not on the process stack,
> +or are part of the kernel text. This kills entire classes
> +of heap overflow exploits and similar kernel memory exposures.
> +
> +
> +CONFIG_HARDENED_USERCOPY_FALLBACK=n
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** None / Aesthetical

This is still self-protection (or "kernel memory integrity"). I would
classify this as Low, but I could see an argument for Medium if
someone trips over a missing whitelist.

> +
> +This is a temporary option that allows missing usercopy whitelists
> +to be discovered via a WARN() to the kernel log, instead of
> +rejecting the copy, falling back to non-whitelisted hardened
> +usercopy that checks the slab allocation size instead of the
> +whitelist size. This option will be removed once it seems like
> +all missing usercopy whitelists have been identified and fixed.
> +Booting with "slab_common.usercopy_fallback=Y/N" can change
> +this setting.
> +
> +
> +CONFIG_HIBERNATION=n
> +~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Self-protection
> +
> +Enabling suspend to disk (STD) functionality (hibernation)
> +allows replacement of running kernel.
> +
> +
> +CONFIG_IA32_EMULATION=n
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Attack surface reduction
> +
> +Include code to run legacy 32-bit programs under a 64-bit kernel.
> +
> +
> +CONFIG_INET_DIAG=n
> +~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Attack surface reduction
> +
> +Support for INET (TCP, DCCP, etc) socket monitoring interface used by
> +native Linux tools such as ss. ss is included in iproute2.
> +In the past, this was used to help heap memory attacks.
> +
> +
> +CONFIG_IO_STRICT_DEVMEM=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium

bikeshed: Low (distros enable this already)

> +**- Protection type:** Self-protection
> +
> +If this option is disabled, you allow userspace (root) access to
> +all io-memory regardless of whether a driver is actively using that
> +range. Accidental access to this is obviously disastrous, but
> +specific access can be used by people debugging kernel drivers.
> +If this option is switched on, the /dev/mem file only allows
> +userspace access to *idle* io-memory ranges (see /proc/iomem)
> +This may break traditional users of /dev/mem (dosemu, legacy X, etc...)
> +if the driver using a given range cannot be disabled.
> +
> +
> +CONFIG_KEXEC=n
> +~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Attack surface reduction
> +
> +kexec is a system call that implements the ability to shutdown your
> +current kernel, and to start another kernel.
> +
> +
> +CONFIG_KEXEC_FILE=n
> +~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Attack surface reduction
> +
> +Enable the kexec file based system call. In contrast to the normal
> +kexec system call this system call takes file descriptors for the
> +kernel and initramfs as arguments.
> +
> +
> +CONFIG_KPROBES=n
> +~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Self-protection
> +
> +Kprobes allows you to trap at almost any kernel address and
> +execute a callback function.
> +
> +
> +CONFIG_LEGACY_PTYS=n
> +~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** User space protection
> +
> +Linux has traditionally used the BSD-like names /dev/ptyxx
> +for masters and /dev/ttyxx for slaves of pseudo
> +terminals. This scheme has a number of problems, including
> +security. This option enables these legacy devices.
> +
> +
> +CONFIG_LEGACY_VSYSCALL_NONE=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low

A rapidly diminishing argument could be made for Medium here.

> +**- Protection type:** User space protection
> +
> +There will be no vsyscall mapping at all. This will
> +eliminate any risk of ASLR bypass due to the vsyscall
> +fixed address mapping. Attempts to use the vsyscalls
> +will be reported to dmesg, so that either old or
> +malicious userspace programs can be identified.
> +
> +
> +CONFIG_LIVEPATCH=n
> +~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Self-protection
> +
> +Kernel live patching support allows root to modify the running
> +kernel. This is mainly used to apply security updates without
> +rebooting, but it might be abused.
> +
> +
> +CONFIG_EXPERT=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** None

"prerequisite"?

> +
> +Needed to change CONFIG_MODIFY_LDT_SYSCALL.
> +
> +
> +CONFIG_MODIFY_LDT_SYSCALL=n
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Attack surface reduction
> +
> +Linux can allow user programs to install a per-process x86
> +Local Descriptor Table (LDT) using the modify_ldt(2) system
> +call. This is required to run 16-bit or segmented code such as
> +DOSEMU or some Wine programs. It is also used by some very old
> +threading libraries.
> +
> +
> +CONFIG_MODULES=n
> +~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Self-protection
> +
> +Kernel modules are small pieces of compiled code which can
> +be inserted in the running kernel, rather than being
> +permanently built into the kernel.
> +
> +
> +CONFIG_MODULE_SIG=y
> +~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +Check modules for valid signatures upon load: the signature
> +is simply appended to the module.
> +
> +
> +CONFIG_MODULE_SIG_ALL=y
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +Sign all modules during make modules_install. Without this option,
> +modules must be signed manually, using the scripts/sign-file tool.
> +
> +
> +CONFIG_MODULE_SIG_FORCE=n
> +~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +Reject unsigned modules or signed modules for which we don't have a
> +key. Without this, such modules will simply taint the kernel.
> +
> +
> +CONFIG_MODULE_SIG_FORCE=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** Self-protection
> +
> +Reject unsigned modules or signed modules for which we don't have a
> +key. Without this, such modules will simply taint the kernel.
> +
> +
> +CONFIG_MODULE_SIG_HASH="sha512"
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +This determines which sort of hashing algorithm will be used during
> +signature generation.
> +
> +
> +CONFIG_MODULE_SIG_SHA512=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +This determines which sort of hashing algorithm will be used during
> +signature generation.
> +
> +
> +CONFIG_PAGE_POISONING=y
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** Self-protection
> +
> +Fill the pages with poison patterns after free_pages() and verify
> +the patterns before alloc_pages. The filling of the memory helps
> +reduce the risk of information leaks from freed data. This does
> +have a potential performance impact.
> +Needs "page_poison=1" command line.
> +
> +
> +CONFIG_PAGE_POISONING_NO_SANITY=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** Self-protection
> +
> +Skip the sanity checking on alloc, only fill the pages with
> +poison on free. This reduces some of the overhead of the
> +poisoning feature.
> +
> +
> +CONFIG_PAGE_POISONING_NO_SANITY=n
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Self-protection
> +
> +Skip the sanity checking on alloc, only fill the pages with
> +poison on free. This reduces some of the overhead of the
> +poisoning feature.
> +
> +
> +CONFIG_PAGE_POISONING_ZERO=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** Self-protection
> +
> +Instead of using the existing poison value, fill the pages with
> +zeros. This makes it harder to detect when errors are occurring
> +due to sanitization but the zeroing at free means that it is
> +no longer necessary to write zeros when GFP_ZERO is used on
> +allocation.
> +
> +
> +CONFIG_PAGE_TABLE_ISOLATION=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High

Oof. This needs to always be on... but it does have a high cost.

> +**- Protection type:** Self-protection
> +
> +This feature reduces the number of hardware side channels by
> +ensuring that the majority of kernel addresses are not mapped
> +into userspace.
> +
> +See Documentation/x86/pti.txt for more details.
> +
> +
> +CONFIG_PANIC_ON_OOPS=y
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Self-protection
> +
> +Say Y here to enable the kernel to panic when it oopses. This
> +has the same effect as setting oops=panic on the kernel command
> +line.
> +
> +
> +CONFIG_PANIC_TIMEOUT=-1
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Self-protection
> +
> +Set the timeout value (in seconds) until a reboot occurs when the
> +the kernel panics. If n = 0, then we wait forever. A timeout
> +value n > 0 will wait n seconds before rebooting, while a timeout
> +value n < 0 will reboot immediately.
> +
> +
> +CONFIG_PROC_KCORE=n
> +~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Self-protection
> +
> +Provides a virtual ELF core file of the live kernel. This can
> +be read with gdb and other ELF tools, exposing kernel layout.
> +
> +
> +CONFIG_PROFILING=n
> +~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme
> +**- Protection type:** Attack surface reduction
> +
> +Enable the extended profiling support mechanisms used
> +by profilers such as OProfile.
> +
> +
> +CONFIG_RANDOMIZE_BASE=y
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +Randomizes the physical and virtual address at which the
> +kernel image is loaded, as a security feature that
> +deters exploit attempts relying on knowledge of the location
> +of kernel internals.
> +
> +
> +CONFIG_RANDOMIZE_MEMORY=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +Randomizes the base virtual address of kernel memory sections
> +(physical memory mapping, vmalloc & vmemmap). This security feature
> +makes exploits relying on predictable memory locations less reliable.
> +
> +
> +CONFIG_REFCOUNT_FULL=y
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High

I'd put this Medium. Though some architectures use this by default (arm64, arm).

> +**- Protection type:** Self-protection
> +
> +Enabling this switches the refcounting infrastructure from a fast
> +unchecked atomic_t implementation to a fully state checked
> +implementation, which can be (slightly) slower but provides protections
> +against various use-after-free conditions that can be used in
> +security flaw exploits.
> +
> +
> +CONFIG_RETPOLINE=y
> +~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** Self-protection
> +
> +Compile kernel with the retpoline compiler options to guard against
> +kernel-to-user data leaks by avoiding speculative indirect
> +branches. Requires a compiler with -mindirect-branch=thunk-extern
> +support for full protection. The kernel may run slower.
> +
> +Without compiler support, at least indirect branches in assembler
> +code are eliminated. Since this includes the syscall entry path,
> +it is not entirely pointless.
> +
> +
> +CONFIG_SCHED_STACK_END_CHECK=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +This option checks for a stack overrun on calls to schedule().
> +If the stack end location is found to be over written always panic as
> +the content of the corrupted region can no longer be trusted.
> +This is to ensure no erroneous behaviour occurs which could result in
> +data corruption or a sporadic crash at a later stage once the region
> +is examined. The runtime overhead introduced is minimal.
> +
> +
> +CONFIG_SECCOMP=y
> +~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** User space protection / Attack surface reduction
> +
> +This kernel feature is useful for number crunching applications
> +that may need to compute untrusted bytecode during their
> +execution.
> +
> +
> +CONFIG_SECCOMP_FILTER=y
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** User space protection / Attack surface reduction
> +
> +Enable tasks to build secure computing environments defined
> +in terms of Berkeley Packet Filter programs which implement
> +task-defined system call filtering polices.
> +
> +See Documentation/prctl/seccomp_filter.txt for details.
> +
> +
> +CONFIG_SECURITY=y
> +~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Generic
> +
> +This allows you to choose different security modules to be
> +configured into your kernel.
> +
> +
> +CONFIG_SECURITY_DMESG_RESTRICT=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** Self-protection
> +
> +This enforces restrictions on unprivileged users reading the kernel
> +syslog via dmesg(8).
> +
> +
> +CONFIG_SECURITY_SELINUX_DISABLE=n
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Generic
> +
> +This option enables writing to a selinuxfs node 'disable', which
> +allows SELinux to be disabled at runtime prior to the policy load.
> +SELinux will then remain disabled until the next boot.
> +
> +
> +CONFIG_SECURITY_YAMA=y
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** User space protection
> +
> +This selects Yama, which extends DAC support with additional
> +system-wide security settings beyond regular Linux discretionary
> +access controls. Currently available is ptrace scope restriction.
> +
> +
> +CONFIG_SLAB_FREELIST_HARDENED=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium

I think this is Low.

> +**- Protection type:** Self-protection
> +
> +Many kernel heap attacks try to target slab cache metadata and
> +other infrastructure. This options makes minor performance
> +sacrifies to harden the kernel slab allocator against common
> +freelist exploit methods.
> +
> +
> +CONFIG_SLAB_FREELIST_RANDOM=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium

Low

> +**- Protection type:** Self-protection
> +
> +Randomizes the freelist order used on creating new pages. This
> +security feature reduces the predictability of the kernel slab
> +allocator against heap overflows.
> +
> +
> +CONFIG_SLUB_DEBUG=y
> +~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High

This should be Low, since it doesn't actually do anything until you
enable features on the cmdline.

> +**- Protection type:** Self-protection
> +
> +Enalbe SLUB debug support features.
> +
> +
> +CONFIG_SLUB_DEBUG_ON=y
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** Self-protection
> +
> +Boot with debugging on by default. SLUB debugging may be switched
> +off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
> +"slub_debug=-".
> +
> +
> +CONFIG_STATIC_USERMODEHELPER=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Extreme

I mean, this SHOULD be Low but no distro has actually implemented a
helper to do this yet.

> +**- Protection type:** Attack surface reduction
> +
> +By default, the kernel can call many different userspace
> +binary programs through the "usermode helper" kernel
> +interface.  Some of these binaries are statically defined
> +either in the kernel code itself, or as a kernel configuration
> +option.  However, some of these are dynamically created at
> +runtime, or can be modified after the kernel has started up.
> +To provide an additional layer of security, route all of these
> +calls through a single executable that can not have its name
> +changed.
> +
> +Note, it is up to this single binary to then call the relevant
> +"real" usermode helper binary, based on the first argument
> +passed to it.  If desired, this program can filter and pick
> +and choose what real programs are called.
> +
> +If you wish for all usermode helper programs are to be
> +disabled, choose this option and then set
> +STATIC_USERMODEHELPER_PATH to an empty string.
> +
> +
> +CONFIG_STRICT_DEVMEM=y

I feel like this should be near IO_DEVMEM and DEVMEM

> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +If this option is disabled, you allow userspace (root) access
> +to all of memory, including kernel and userspace memory.
> +Accidental access to this is obviously disastrous, but specific
> +access can be used by people debugging the kernel.
> +If this option is switched on, the /dev/mem file only allows
> +userspace access to memory mapped peripherals.
> +
> +
> +CONFIG_STRICT_KERNEL_RWX=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +Kernel text and rodata memory will be made read-only, and non-text memory will
> +be made non-executable. This provides protection against certain security
> +exploits (e.g. executing the heap or modifying text).
> +These features are considered standard security practice these days.
> +
> +
> +CONFIG_STRICT_MODULE_RWX=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +If this is set, module text and rodata memory will be made read-only,
> +and non-text memory will be made non-executable. This provides
> +protection against certain security exploits (e.g. writing to text)
> +
> +
> +CONFIG_SYN_COOKIES=y
> +~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** User space protection
> +
> +Normal TCP/IP networking is open to an attack known as "SYN flooding".
> +This denial-of-service attack prevents legitimate remote users from being
> +able to connect to your computer during an ongoing attack and requires very
> +little work from the attacker, who can operate from anywhere on the Internet.
> +SYN cookies provide protection against this type of attack.
> +SYN cookies may prevent correct error reporting on clients when the server is
> +really overloaded. If this happens frequently better turn them off.
> +Note that SYN cookies aren't enabled by default; you can enable them by saying
> +Y to "/proc file system support" and "Sysctl support" below and executing the
> +command:
> +
> +echo 1 >/proc/sys/net/ipv4/tcp_syncookies
> +
> +at boot time after the /proc file system has been mounted.
> +
> +
> +CONFIG_THREAD_INFO_IN_TASK=y
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +Move thread_info off the stack into task_struct.
> +
> +
> +CONFIG_UPROBES=n
> +~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** High
> +**- Protection type:** User space protection
> +
> +Uprobes is the user-space counterpart to kprobes: they
> +enable instrumentation applications (such as 'perf probe')
> +to establish unintrusive probes in user-space binaries and
> +libraries, by executing handler functions when the probes
> +are hit by user-space applications.
> +
> +
> +CONFIG_USER_NS=n
> +~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium

Unfortunately I think this is High or Extreme. USER_NS gets a lot of use.

> +**- Protection type:** Attack surface reduction
> +
> +This allows containers to use user namespaces to provide different
> +user info for different servers.
> +User namespaces have been abused in the past for privilege
> +escalation.
> +
> +
> +CONFIG_VMAP_STACK=y
> +~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Low
> +**- Protection type:** Self-protection
> +
> +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.
> +
> +
> +CONFIG_X86_SMAP=y
> +~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium

This is Low.

> +**- Protection type:** Self-protection
> +
> +Supervisor Mode Access Prevention (SMAP) is a security feature in newer
> +Intel processors. There is a small performance cost if this enabled and
> +turned on; there is also a small increase in the kernel size if this is
> +enabled.
> +
> +
> +CONFIG_X86_INTEL_MPX=y
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium
> +**- Protection type:** User space protection

No idea what to do with this one. Support is being removed, etc.

> +
> +MPX provides hardware features that can be used in conjunction with
> +compiler-instrumented code to check memory references. It is designed
> +to detect buffer overflow or underflow bugs.
> +This option enables running applications which are instrumented or
> +otherwise use MPX. It does not use MPX itself inside the kernel or to
> +protect the kernel against bad memory references.
> +
> +
> +CONFIG_X86_INTEL_UMIP=y
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Negative side effects level:** Medium

Low?

> +**- Protection type:** Information leak prevention
> +
> +The User Mode Instruction Prevention (UMIP) is a security feature in newer
> +Intel processors. If enabled, a general protection fault is issued if the
> +SGDT, SLDT, SIDT, SMSW or STR instructions are executed in user mode.
> +These instructions unnecessarily expose information about the hardware state.
> +The vast majority of applications do not use these instructions. For the very
> +few that do, software emulation is provided in specific cases in protected and
> +virtual-8086 modes. Emulated results are dummy.
> diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst
> index 85492bf..01b8265 100644
> --- a/Documentation/security/index.rst
> +++ b/Documentation/security/index.rst
> @@ -13,3 +13,4 @@ Security Documentation
>     SELinux-sctp
>     self-protection
>     tpm/index
> +   hardenedconfig
> diff --git a/Makefile b/Makefile
> index a89d8a0..e967504 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1282,7 +1282,11 @@ MRPROPER_FILES += .config .config.old .version \
>                   Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
>                   signing_key.pem signing_key.priv signing_key.x509     \
>                   x509.genkey extra_certificates signing_key.x509.keyid \
> -                 signing_key.x509.signer vmlinux-gdb.py
> +                 signing_key.x509.signer vmlinux-gdb.py        \
> +                 kernel/configs/hardenedlow.config     \
> +                 kernel/configs/hardenedmedium.config  \
> +                 kernel/configs/hardenedhigh.config    \
> +                 kernel/configs/hardenedextreme.config
>
>  # clean - Delete most, but leave enough to build external modules
>  #
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index a3ac2c9..b5ebb13 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -100,6 +100,16 @@ endif
>
>  configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/configs/$@)
>
> +hardened%.config:
> +       $(srctree)/scripts/kconfig/build_hardened_fragment.sh \

I think this needs explicit execution (as you do a few lines later) with:

    $(CONFIG_SHELL) $(srctree)/scripts/kconfig/build_hardened_fragment.sh \
...

since the execute bit regularly gets lost in vcs, bundles, etc.

> +       $* $(srctree)/Documentation/security/hardenedconfig.rst > \
> +       $(srctree)/kernel/configs/hardened$*.config
> +       $(eval configfiles += $(srctree)/kernel/configs/hardened$*.config)
> +
> +       $(if $(call configfiles),, $(error No configuration exists for this target on this architecture))
> +       $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m .config $(configfiles)
> +       +$(Q)yes "" | $(MAKE) -f $(srctree)/Makefile oldconfig
> +
>  %.config: $(obj)/conf
>         $(if $(call configfiles),, $(error No configuration exists for this target on this architecture))
>         $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m .config $(configfiles)
> @@ -117,6 +127,16 @@ PHONY += tinyconfig
>  tinyconfig:
>         $(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config
>
> +PHONY += hardenedlowconfig hardenedmediumconfig hardenedhighconfig hardenedextremeconfig
> +hardenedlowconfig: hardenedlow.config
> +       @:
> +hardenedmediumconfig: hardenedmedium.config
> +       @:
> +hardenedhighconfig: hardenedhigh.config
> +       @:
> +hardenedextremeconfig: hardenedextreme.config
> +       @:
> +
>  # CHECK: -o cache_dir=<path> working?
>  PHONY += testconfig
>  testconfig: $(obj)/conf
> @@ -127,28 +147,36 @@ clean-dirs += tests/.cache
>
>  # Help text used by make help
>  help:
> -       @echo  '  config          - Update current config utilising a line-oriented program'
> -       @echo  '  nconfig         - Update current config utilising a ncurses menu based program'
> -       @echo  '  menuconfig      - Update current config utilising a menu based program'
> -       @echo  '  xconfig         - Update current config utilising a Qt based front-end'
> -       @echo  '  gconfig         - Update current config utilising a GTK+ based front-end'
> -       @echo  '  oldconfig       - Update current config utilising a provided .config as base'
> -       @echo  '  localmodconfig  - Update current config disabling modules not loaded'
> -       @echo  '  localyesconfig  - Update current config converting local mods to core'
> -       @echo  '  defconfig       - New config with default from ARCH supplied defconfig'
> -       @echo  '  savedefconfig   - Save current config as ./defconfig (minimal config)'
> -       @echo  '  allnoconfig     - New config where all options are answered with no'
> -       @echo  '  allyesconfig    - New config where all options are accepted with yes'
> -       @echo  '  allmodconfig    - New config selecting modules when possible'
> -       @echo  '  alldefconfig    - New config with all symbols set to default'
> -       @echo  '  randconfig      - New config with random answer to all options'
> -       @echo  '  listnewconfig   - List new options'
> -       @echo  '  olddefconfig    - Same as oldconfig but sets new symbols to their'
> -       @echo  '                    default value without prompting'
> -       @echo  '  kvmconfig       - Enable additional options for kvm guest kernel support'
> -       @echo  '  xenconfig       - Enable additional options for xen dom0 and guest kernel support'
> -       @echo  '  tinyconfig      - Configure the tiniest possible kernel'
> -       @echo  '  testconfig      - Run Kconfig unit tests (requires python3 and pytest)'

Can these whitespace changes be avoided?

> +       @echo  '  config                - Update current config utilising a line-oriented program'
> +       @echo  '  nconfig               - Update current config utilising a ncurses menu based program'
> +       @echo  '  menuconfig            - Update current config utilising a menu based program'
> +       @echo  '  xconfig               - Update current config utilising a Qt based front-end'
> +       @echo  '  gconfig               - Update current config utilising a GTK+ based front-end'
> +       @echo  '  oldconfig             - Update current config utilising a provided .config as base'
> +       @echo  '  localmodconfig        - Update current config disabling modules not loaded'
> +       @echo  '  localyesconfig        - Update current config converting local mods to core'
> +       @echo  '  defconfig             - New config with default from ARCH supplied defconfig'
> +       @echo  '  savedefconfig         - Save current config as ./defconfig (minimal config)'
> +       @echo  '  allnoconfig           - New config where all options are answered with no'
> +       @echo  '  allyesconfig          - New config where all options are accepted with yes'
> +       @echo  '  allmodconfig          - New config selecting modules when possible'
> +       @echo  '  alldefconfig          - New config with all symbols set to default'
> +       @echo  '  randconfig            - New config with random answer to all options'
> +       @echo  '  listnewconfig         - List new options'
> +       @echo  '  olddefconfig          - Same as oldconfig but sets new symbols to their'
> +       @echo  '                          default value without prompting'
> +       @echo  '  kvmconfig             - Enable additional options for kvm guest kernel support'
> +       @echo  '  xenconfig             - Enable additional options for xen dom0 and guest kernel support'
> +       @echo  '  tinyconfig            - Configure the tiniest possible kernel'
> +       @echo  '  testconfig            - Run Kconfig unit tests (requires python3 and pytest)'
> +       @echo  '  hardenedlowconfig     - Update current config using hardened features with'
> +       @echo  '                          few negative side effects'
> +       @echo  '  hardenedmediumconfig  - Update current config using hardened features with'
> +       @echo  '                          some negative side effects'
> +       @echo  '  hardenedhighconfig    - Update current config using hardened features with'
> +       @echo  '                          many negative side effects'
> +       @echo  '  hardenedextremeconfig - Update current config using hardened features with'
> +       @echo  '                          even more negative side effects'
>
>  # ===========================================================================
>  # Shared Makefile for the various kconfig executables:
> diff --git a/scripts/kconfig/build_hardened_fragment.sh b/scripts/kconfig/build_hardened_fragment.sh
> new file mode 100755
> index 0000000..92c589a
> --- /dev/null
> +++ b/scripts/kconfig/build_hardened_fragment.sh
> @@ -0,0 +1,54 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +#  build_hardened_fragment.sh - Generate a config fragment from an .rst
> +#  file for the specified level.
> +#
> +#  Copyright 2018 Salvatore Mesoraca <s.mesoraca16@gmail.com>
> +#
> +#  This program is free software; you can redistribute it and/or modify
> +#  it under the terms of the GNU General Public License version 2 as
> +#  published by the Free Software Foundation.
> +#
> +#  This program is distributed in the hope that it will be useful,
> +#  but WITHOUT ANY WARRANTY; without even the implied warranty of
> +#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> +#  See the GNU General Public License for more details.
> +
> +usage() {
> +       echo "Usage: $0 <level> <file.rst>"
> +       echo "Level must be one of: low, medium, high, extreme."

I would send these to stderr:   >&2

> +       exit 1
> +}
> +
> +if [ "$#" -ne 2 ]; then
> +       usage
> +fi
> +
> +LEVEL="$(echo $1 | tr [A-Z] [a-z])"
> +INPUT="$2"
> +
> +if [ "$LEVEL" != "low" ] && \
> +   [ "$LEVEL" != "medium" ] && \
> +   [ "$LEVEL" != "high" ] && \
> +   [ "$LEVEL" != "extreme" ]; then
> +       usage
> +fi
> +
> +if ! [ -f "$INPUT" ]; then
> +       usage
> +fi
> +
> +if [ "$LEVEL" = "medium" ]; then
> +       LEVEL="(low|medium)"
> +elif [ "$LEVEL" = "high" ]; then
> +       LEVEL="(low|medium|high)"
> +elif [ "$LEVEL" = "extreme" ]; then
> +       LEVEL="(low|medium|high|extreme)"
> +fi
> +
> +egrep -B3 -i "^\*\*Negative side effects level:\*\* $LEVEL$" "$INPUT" | \
> +grep "^CONFIG_" | \
> +sed 's/^\(.*\)=[nN]/# \1 is not set/'
> +
> +exit 0
> --
> 1.9.1
>

Cool! I think being able to point into this document from the
self-protection.rst will be nice.

-Kees

-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kconfig: add hardened defconfig helpers

[Eric W. Biederman]

Kees Cook <keescook@chromium.org> writes:

>> +CONFIG_USER_NS=n
>> +~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>
> Unfortunately I think this is High or Extreme. USER_NS gets a lot of use.
>
>> +**- Protection type:** Attack surface reduction
>> +
>> +This allows containers to use user namespaces to provide different
>> +user info for different servers.
>> +User namespaces have been abused in the past for privilege
>> +escalation.

This is not a particularly good description.

User namespaces do indeed increase the attack surface of programs that
don't use them.

User namespaces when used to build ``unprivileged containers'' remove or
at least drastically reduce the need to run as root when setting up
containers.  Which is attack surface reduction.

User namespaces make available tools that are commonly used to build
sandboxes.  Chrome for example uses users namespaces if they are
available as part of setting up it's sandbox.

User namespaces are not limited to containers.

The bugs in the attack surface that user namespaces expose that have
been used for privilege escalation have to the best of my knowledge
closed.  So while there is some danger in the increased attack surface
we are looking at implementation defects rather than design defects.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kconfig: add hardened defconfig helpers

[Salvatore Mesoraca]

2018-07-20 15:37 GMT+02:00 Eric W. Biederman <ebiederm@xmission.com>:
> Kees Cook <keescook@chromium.org> writes:
>
>>> +CONFIG_USER_NS=n
>>> +~~~~~~~~~~~~~~~~
>>> +
>>> +**Negative side effects level:** Medium
>>
>> Unfortunately I think this is High or Extreme. USER_NS gets a lot of use.
>>
>>> +**- Protection type:** Attack surface reduction
>>> +
>>> +This allows containers to use user namespaces to provide different
>>> +user info for different servers.
>>> +User namespaces have been abused in the past for privilege
>>> +escalation.
>
> This is not a particularly good description.

You are right, I've been a bit shallow...
Thank you for pointing it out.
I didn't mean to say that user namespaces are bad for security in general.
I'll make this less ambiguous in the next revision.

> User namespaces do indeed increase the attack surface of programs that
> don't use them.
>
> User namespaces when used to build ``unprivileged containers'' remove or
> at least drastically reduce the need to run as root when setting up
> containers.  Which is attack surface reduction.
>
> User namespaces make available tools that are commonly used to build
> sandboxes.  Chrome for example uses users namespaces if they are
> available as part of setting up it's sandbox.
>
> User namespaces are not limited to containers.
>
> The bugs in the attack surface that user namespaces expose that have
> been used for privilege escalation have to the best of my knowledge
> closed.  So while there is some danger in the increased attack surface
> we are looking at implementation defects rather than design defects.
>
> Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kconfig: add hardened defconfig helpers

[Masahiro Yamada]

2018-07-20 14:15 GMT+09:00 Kees Cook <keescook@chromium.org>:
> +lkml, Masahiro, and linux-doc, just for wider review/thoughts.


I do not subscribe to kernel-hardening ML.

I do not see the original patch in lkml or kbuild/kconfig ML.


> On Wed, Jul 18, 2018 at 10:38 AM, Salvatore Mesoraca
> <s.mesoraca16@gmail.com> wrote:
>> Adds 4 new defconfig helpers (hardenedlowconfig,
>> hardenedmediumconfig, hardenedhighconfig,
>> hardenedextremeconfig) to enable various hardening
>> features.
>> The list of config options to enable is based on
>> KSPP's Recommended Settings[1] and on
>> kconfig-hardened-check[2], with some modifications.
>> These options are divided into 4 levels (low, medium,
>> high, extreme) based on their negative side effects, not
>> on their usefulness.
>> 'Low' level collects all those protections that have
>> (almost) no negative side effects.
>
> Likely the "Low" should be on-by-default already, but it's easier to
> bike-shed that separately. :)
>
>> 'Extreme' level collects those protections that may have
>> some many negative side effects that most people
>> wouldn't want to enable them.
>> Every feature in each level is briefly documented in
>> Documentation/security/hardenedconfig.rst, this file
>> also contain a better explanation of what every level
>> means.
>> To prevent this file from drifting from what the various
>> defconfigs actually do, it is used to dynamically
>> generate the config fragments.
>
> I like that the configs are generated from the docs! This makes things
> very sane to update.
>
>>
>> [1] http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
>> [2] https://github.com/a13xp0p0v/kconfig-hardened-check
>>
>> Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
>> ---
>>  .gitignore                                 |    6 +
>>  Documentation/security/hardenedconfig.rst  | 1027 ++++++++++++++++++++++++++++
>>  Documentation/security/index.rst           |    1 +
>>  Makefile                                   |    6 +-
>>  scripts/kconfig/Makefile                   |   72 +-
>>  scripts/kconfig/build_hardened_fragment.sh |   54 ++
>>  6 files changed, 1143 insertions(+), 23 deletions(-)
>>  create mode 100644 Documentation/security/hardenedconfig.rst
>>  create mode 100755 scripts/kconfig/build_hardened_fragment.sh
>>

-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kconfig: add hardened defconfig helpers

[Kees Cook]

On Sun, Jul 22, 2018 at 6:55 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> 2018-07-20 14:15 GMT+09:00 Kees Cook <keescook@chromium.org>:
>> +lkml, Masahiro, and linux-doc, just for wider review/thoughts.
>
>
> I do not subscribe to kernel-hardening ML.
>
> I do not see the original patch in lkml or kbuild/kconfig ML.

Here's the start of the thread:
http://www.openwall.com/lists/kernel-hardening/2018/07/18/1

-Kees

-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kconfig: add hardened defconfig helpers

[Salvatore Mesoraca]

I'm sorry for the late response, I've been unexpectedly busy in the last week.

2018-07-20 7:15 GMT+02:00 Kees Cook <keescook@chromium.org>:
> +lkml, Masahiro, and linux-doc, just for wider review/thoughts.
>
> On Wed, Jul 18, 2018 at 10:38 AM, Salvatore Mesoraca
> <s.mesoraca16@gmail.com> wrote:
>> Adds 4 new defconfig helpers (hardenedlowconfig,
>> hardenedmediumconfig, hardenedhighconfig,
>> hardenedextremeconfig) to enable various hardening
>> features.
>> The list of config options to enable is based on
>> KSPP's Recommended Settings[1] and on
>> kconfig-hardened-check[2], with some modifications.
>> These options are divided into 4 levels (low, medium,
>> high, extreme) based on their negative side effects, not
>> on their usefulness.
>> 'Low' level collects all those protections that have
>> (almost) no negative side effects.
>
> Likely the "Low" should be on-by-default already, but it's easier to
> bike-shed that separately. :)
>
>> 'Extreme' level collects those protections that may have
>> some many negative side effects that most people
>> wouldn't want to enable them.
>> Every feature in each level is briefly documented in
>> Documentation/security/hardenedconfig.rst, this file
>> also contain a better explanation of what every level
>> means.
>> To prevent this file from drifting from what the various
>> defconfigs actually do, it is used to dynamically
>> generate the config fragments.
>
> I like that the configs are generated from the docs! This makes things
> very sane to update.
>
>>
>> [1] http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
>> [2] https://github.com/a13xp0p0v/kconfig-hardened-check
>>
>> Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
>> ---
>>  .gitignore                                 |    6 +
>>  Documentation/security/hardenedconfig.rst  | 1027 ++++++++++++++++++++++++++++
>>  Documentation/security/index.rst           |    1 +
>>  Makefile                                   |    6 +-
>>  scripts/kconfig/Makefile                   |   72 +-
>>  scripts/kconfig/build_hardened_fragment.sh |   54 ++
>>  6 files changed, 1143 insertions(+), 23 deletions(-)
>>  create mode 100644 Documentation/security/hardenedconfig.rst
>>  create mode 100755 scripts/kconfig/build_hardened_fragment.sh
>>
>> diff --git a/.gitignore b/.gitignore
>> index 97ba6b7..9141f85 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -132,3 +132,9 @@ all.config
>>
>>  # Kdevelop4
>>  *.kdev4
>> +
>> +# Generated config fragments
>> +kernel/configs/hardenedlow.config
>> +kernel/configs/hardenedmedium.config
>> +kernel/configs/hardenedhigh.config
>> +kernel/configs/hardenedextreme.config
>
> I wonder if there should be an explicit "generated/" subdirectory in
> kernel/configs/ ?

Yes, that woud probably be better.

>> diff --git a/Documentation/security/hardenedconfig.rst b/Documentation/security/hardenedconfig.rst
>> new file mode 100644
>> index 0000000..04ae0d9
>> --- /dev/null
>> +++ b/Documentation/security/hardenedconfig.rst
>
> And thank you for doing this in .rst!
>
>> @@ -0,0 +1,1027 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +===============================
>> +Hardening Configuration Options
>> +===============================
>> +
>> +This is a list of configuration options that are useful for hardening purposes.
>> +These options are divided in 4 levels based on the magnitude of their negative
>> +side effects, not on their importance or usefulness:
>> +
>> +       - **Low**: Negligible performance impact. No user-space breakage.
>> +       - **Medium**: Some performance impact and/or user-space breakage for
>> +         few users.
>> +       - **High**: Notable performance impact and/or user-space breakage for
>> +         many users.
>> +       - **Extreme**: Big performance impact and/or user-space breakage for
>> +         most users.
>> +
>> +In other words: **Low** level contains protections that *everybody* can and
>> +should use; **Medium** level should be usable by *most people* without issues;
>> +**High** level may cause *some trouble*, especially from a *performance*
>> +perspective; **Extreme** level contains protections that *few people* may want
>> +to enable, some people will probably *cherry-pick* some options from here based
>> +on their needs.
>> +
>> +For further details about which option is included in each level, please read
>> +the description below, for more information on any particular option refer to
>> +their help page.
>> +
>> +The content of this list is automatically translated into *config fragments*
>> +that can be used to apply the suggested hardening options to your current
>> +configuration.
>> +To use them you just need to run ``make hardened$LEVELconfig`` (e.g.
>> +``make hardenedhighconfig``).
>> +
>> +
>> +
>> +CONFIG_ACPI_CUSTOM_METHOD=n
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Self-protection
>
> Rather than "self-protection", this is really about blocking direct
> kernel memory writing from userspace. Maybe "Kernel memory integrity"?

OK. I'll change it.

>> +
>> +This debug facility allows ACPI AML methods to be inserted and/or replaced
>> +without rebooting the system.
>> +This option is security sensitive, because it allows arbitrary kernel
>> +memory to be written to by root (uid=0) users, allowing them to bypass
>> +certain security measures (e.g. if root is not allowed to load additional
>> +kernel modules after boot, this feature may be used to override that
>> +restriction).
>> +
>> +
>> +CONFIG_BPF_JIT=n
>> +~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** Attack surface reduction
>
> This maybe should be clarified to "Kernel attack surface reduction"?

OK. I'll change it.

>> +
>> +Berkeley Packet Filter filtering capabilities are normally handled
>> +by an interpreter. This option allows kernel to generate a native
>> +code when filter is loaded in memory. This should speedup
>> +packet sniffing (libpcap/tcpdump).
>> +
>> +Note, admin should enable this feature changing:
>> +/proc/sys/net/core/bpf_jit_enable
>> +/proc/sys/net/core/bpf_jit_harden   (optional)
>> +/proc/sys/net/core/bpf_jit_kallsyms (optional)
>> +
>> +
>> +CONFIG_BPF_SYSCALL=n
>> +~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Attack surface reduction
>
> Same.

OK. I'll change it.

>> +
>> +Enable the bpf() system call that allows to manipulate eBPF
>> +programs and maps via file descriptors.
>> +
>> +
>> +CONFIG_BUG=y
>> +~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>
> This was a left-over mistaken prerequisite for hardened-usercopy.
> Without CONFIG_BUG, things will still stop kernel thread execution.
> It's just much less pretty. :P Perhaps, if kept, this should be listed
> as "Improved crash analysis" or "prerequisite"?

Ah, I wasn't sure about the reason why CONFIG_BUG was needed.
If it's just about error reporting I'll drop it.

>> +
>> +Report BUG() conditions and kill the offending process.
>> +There are very few cases in which this won't be desirable.
>> +
>> +
>> +CONFIG_BUG_ON_DATA_CORRUPTION=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** Self-protection
>> +
>> +Select this option if the kernel should BUG when it encounters
>> +data corruption in kernel memory structures when they get checked
>> +for validity.
>> +
>> +
>> +CONFIG_CC_STACKPROTECTOR=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Self-protection
>
> "probabilistic kernel stack buffer overflow detection"?
>
> There are a lot of "buffer overflow detection" things, so naming which
> is which seems helpful, but is maybe overkill? "Self-protection" or
> "kernel memory integrity" covers it too... hmmm

I don't know, maybe we should leave the "Protection type" field as
simple as possible and then use the description to make things
clearer.
But I'm not against changing it...

>> +
>> +Turns on the "stack-protector" GCC feature. This feature puts,
>> +at the beginning of functions, a canary value on
>> +the stack just before the return address, and validates
>> +the value just before actually returning.  Stack based buffer
>> +overflows (that need to overwrite this return address) now also
>> +overwrite the canary, which gets detected and the attack is then
>> +neutralized via a kernel panic.
>> +
>> +
>> +CONFIG_CC_STACKPROTECTOR_STRONG=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Self-protection
>> +
>> +Functions will have the stack-protector canary logic added in any
>> +of the following conditions:
>> +
>> +- local variable's address used as part of the right hand side of an
>> +assignment or function argument
>> +- local variable is an array (or union containing an array),
>> +regardless of array type or length
>> +- uses register local variables
>> +
>> +This feature requires gcc version 4.9 or above, or a distribution
>> +gcc with the feature backported ("-fstack-protector-strong").
>> +
>> +On an x86 "defconfig" build, this feature adds canary checks to
>> +about 20% of all kernel functions, which increases the kernel code
>> +size by about 2%.
>
> bikeshed: I think both stack protector items should be "Low", but
> that's just me.

I tried to be cautious when selecting the levels, but if nobody is
against it, I can change the level.

>> +
>> +
>> +CONFIG_COMPAT_BRK=n
>> +~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>
> This is a userspace defense. "Userspace brk ASLR"?

Ops... my bad

>> +
>> +Randomizing heap placement makes heap exploits harder, but it
>> +also breaks ancient binaries (including anything libc5 based).
>> +This option changes the bootup default to heap randomization
>> +disabled, and can be overridden at runtime by setting
>> +/proc/sys/kernel/randomize_va_space to 2.
>> +
>> +On non-ancient distros (post-2000 ones) N is usually a safe choice.
>> +
>> +
>> +CONFIG_COMPAT_VDSO=n
>> +~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** User space protection
>> +
>> +
>> +Map the VDSO to the predictable old-style address too.
>> +Glibc 2.3.3 is the only version that needs it, but
>> +OpenSUSE 9 contains a buggy "glibc 2.3.2".
>> +
>> +
>> +CONFIG_DEBUG_CREDENTIALS=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Self-protection
>> +
>> +Turn on some debug checking for credential management.
>> +These structs are often abused by attackers.
>> +
>> +
>> +CONFIG_DEBUG_LIST=y
>> +~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>
> bikeshed: Low

Same as with stackprotector.

>
>> +**- Protection type:** Self-protection
>> +
>> +Turn on extended checks in the linked-list walking routines.
>> +These structs are often abused by attackers.
>> +
>> +
>> +CONFIG_DEBUG_NOTIFIERS=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Self-protection
>> +
>> +Turn on sanity checking for notifier call chains.
>> +These structs are often abused by attackers.
>> +
>> +
>> +CONFIG_DEBUG_SG=y
>> +~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Self-protection
>> +
>> +Turn on checks on scatter-gather tables.
>> +These structs could be abused by attackers.
>> +
>> +
>> +CONFIG_DEBUG_WX=y
>> +~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +Generate a warning if any W+X mappings are found at boot.
>> +This is useful for discovering cases where the kernel is leaving W+X
>> +mappings after applying NX, as such mappings are a security risk.
>> +There is no runtime or memory usage effect of this option once the
>> +kernel has booted up - it's a one time check.
>> +
>> +
>> +CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
>
> This is, unfortunately, architecture-specific. I'm not sure the best
> way to deal with that with the make target...

Ah, you are right... If I won't find any reasonable way to set this
option to the correcte value on every arch I'll drop it.

>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +This is the portion of low virtual memory which should be protected
>> +from userspace allocation.  Keeping a user from writing to low pages
>> +can help reduce the impact of kernel NULL pointer bugs.
>> +
>> +This value can be changed after boot using the
>> +/proc/sys/vm/mmap_min_addr tunable.
>> +
>> +
>> +CONFIG_DEVKMEM=n
>> +~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +The /dev/kmem device can be used by root to access kernel virtual memory.
>> +It is rarely used, but can be used for certain kind of kernel debugging
>> +operations.
>> +
>> +
>> +CONFIG_DEVMEM=n
>> +~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>
> Why is this extreme?

I tried to be very cautious and I had the impression that this option
could break many programs,
isn't Xorg one of these?

>> +**- Protection type:** Self-protection
>> +
>> +The /dev/mem device is used to access areas of physical
>> +memory.
>> +
>> +
>> +CONFIG_FORTIFY_SOURCE=y
>> +~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +Detect overflows of buffers in common string and memory functions
>> +where the compiler can determine and validate the buffer sizes.
>> +
>> +
>> +CONFIG_FTRACE=n
>> +~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Self-protection
>
> bikeshed: Kernel attack surface reduction

Agreed

>> +
>> +Enable the kernel tracing infrastructure.
>> +
>> +
>> +CONFIG_GCC_PLUGINS=y
>> +~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>
> "prerequisite"

Agreed

>> +
>> +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_LATENT_ENTROPY=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** Self-protection
>> +
>> +With this pluging, the kernel will instrument some kernel code to
>> +extract some entropy from both original and artificially created
>> +program state. This will help especially embedded systems where
>> +there is little 'natural' source of entropy normally.  The cost
>> +is some slowdown of the boot process (about 0.5%) and fork and
>
> This doesn't feel like "high" to me.

Medium maybe?

>> +irq processing.
>> +Note that entropy extracted this way is not cryptographically
>> +secure!
>> +
>> +
>> +CONFIG_GCC_PLUGIN_RANDSTRUCT=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>
> This should surely be High or Extreme. It creates (nondeterministic)
> performance impact and makes crashes undebuggable.

Agreed.

>> +**- Protection type:** Self-protection
>> +
>> +With this pluging, the layouts of structures that are entirely
>> +function pointers (and have not been manually annotated with
>> +__no_randomize_layout), or structures that have been explicitly
>> +marked with __randomize_layout, will be randomized at compile-time.
>> +This can introduce the requirement of an additional information
>> +exposure vulnerability for exploits targeting these structure
>> +types.
>> +Enabling this feature will introduce some performance impact,
>> +slightly increase memory usage, and prevent the use of forensic
>> +tools like Volatility against the system (unless the kernel
>> +source tree isn't cleaned after kernel installation).
>> +
>> +
>> +CONFIG_GCC_PLUGIN_STRUCTLEAK=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>
> bikeshed: Low

Agreed.

>> +**- Protection type:** Self-protection
>> +
>> +This plugin zero-initializes any structures containing a
>> +__user attribute. This can prevent some classes of information
>> +exposures.
>> +
>> +
>> +CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Self-protection
>> +
>> +Zero initialize any struct type local variable that may be passed by
>> +reference without having been initialized.
>> +
>> +
>> +CONFIG_HARDENED_USERCOPY=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>
> bikeshed: Low (all distros have this enabled already)

Agreed.

>> +**- Protection type:** Self-protection
>> +
>> +This option checks for obviously wrong memory regions when
>> +copying memory to/from the kernel (via copy_to_user() and
>> +copy_from_user() functions) by rejecting memory ranges that
>> +are larger than the specified heap object, span multiple
>> +separately allocated pages, are not on the process stack,
>> +or are part of the kernel text. This kills entire classes
>> +of heap overflow exploits and similar kernel memory exposures.
>> +
>> +
>> +CONFIG_HARDENED_USERCOPY_FALLBACK=n
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** None / Aesthetical
>
> This is still self-protection (or "kernel memory integrity"). I would
> classify this as Low, but I could see an argument for Medium if
> someone trips over a missing whitelist.

Oh, right! I'll go for Medium, to be conservative.

>> +
>> +This is a temporary option that allows missing usercopy whitelists
>> +to be discovered via a WARN() to the kernel log, instead of
>> +rejecting the copy, falling back to non-whitelisted hardened
>> +usercopy that checks the slab allocation size instead of the
>> +whitelist size. This option will be removed once it seems like
>> +all missing usercopy whitelists have been identified and fixed.
>> +Booting with "slab_common.usercopy_fallback=Y/N" can change
>> +this setting.
>> +
>> +
>> +CONFIG_HIBERNATION=n
>> +~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Self-protection
>> +
>> +Enabling suspend to disk (STD) functionality (hibernation)
>> +allows replacement of running kernel.
>> +
>> +
>> +CONFIG_IA32_EMULATION=n
>> +~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Attack surface reduction
>> +
>> +Include code to run legacy 32-bit programs under a 64-bit kernel.
>> +
>> +
>> +CONFIG_INET_DIAG=n
>> +~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Attack surface reduction
>> +
>> +Support for INET (TCP, DCCP, etc) socket monitoring interface used by
>> +native Linux tools such as ss. ss is included in iproute2.
>> +In the past, this was used to help heap memory attacks.
>> +
>> +
>> +CONFIG_IO_STRICT_DEVMEM=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>
> bikeshed: Low (distros enable this already)

Agreed.

>> +**- Protection type:** Self-protection
>> +
>> +If this option is disabled, you allow userspace (root) access to
>> +all io-memory regardless of whether a driver is actively using that
>> +range. Accidental access to this is obviously disastrous, but
>> +specific access can be used by people debugging kernel drivers.
>> +If this option is switched on, the /dev/mem file only allows
>> +userspace access to *idle* io-memory ranges (see /proc/iomem)
>> +This may break traditional users of /dev/mem (dosemu, legacy X, etc...)
>> +if the driver using a given range cannot be disabled.
>> +
>> +
>> +CONFIG_KEXEC=n
>> +~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Attack surface reduction
>> +
>> +kexec is a system call that implements the ability to shutdown your
>> +current kernel, and to start another kernel.
>> +
>> +
>> +CONFIG_KEXEC_FILE=n
>> +~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Attack surface reduction
>> +
>> +Enable the kexec file based system call. In contrast to the normal
>> +kexec system call this system call takes file descriptors for the
>> +kernel and initramfs as arguments.
>> +
>> +
>> +CONFIG_KPROBES=n
>> +~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Self-protection
>> +
>> +Kprobes allows you to trap at almost any kernel address and
>> +execute a callback function.
>> +
>> +
>> +CONFIG_LEGACY_PTYS=n
>> +~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** User space protection
>> +
>> +Linux has traditionally used the BSD-like names /dev/ptyxx
>> +for masters and /dev/ttyxx for slaves of pseudo
>> +terminals. This scheme has a number of problems, including
>> +security. This option enables these legacy devices.
>> +
>> +
>> +CONFIG_LEGACY_VSYSCALL_NONE=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>
> A rapidly diminishing argument could be made for Medium here.

OK.

>> +**- Protection type:** User space protection
>> +
>> +There will be no vsyscall mapping at all. This will
>> +eliminate any risk of ASLR bypass due to the vsyscall
>> +fixed address mapping. Attempts to use the vsyscalls
>> +will be reported to dmesg, so that either old or
>> +malicious userspace programs can be identified.
>> +
>> +
>> +CONFIG_LIVEPATCH=n
>> +~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Self-protection
>> +
>> +Kernel live patching support allows root to modify the running
>> +kernel. This is mainly used to apply security updates without
>> +rebooting, but it might be abused.
>> +
>> +
>> +CONFIG_EXPERT=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** None
>
> "prerequisite"?

OK.

>> +
>> +Needed to change CONFIG_MODIFY_LDT_SYSCALL.
>> +
>> +
>> +CONFIG_MODIFY_LDT_SYSCALL=n
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Attack surface reduction
>> +
>> +Linux can allow user programs to install a per-process x86
>> +Local Descriptor Table (LDT) using the modify_ldt(2) system
>> +call. This is required to run 16-bit or segmented code such as
>> +DOSEMU or some Wine programs. It is also used by some very old
>> +threading libraries.
>> +
>> +
>> +CONFIG_MODULES=n
>> +~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Self-protection
>> +
>> +Kernel modules are small pieces of compiled code which can
>> +be inserted in the running kernel, rather than being
>> +permanently built into the kernel.
>> +
>> +
>> +CONFIG_MODULE_SIG=y
>> +~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +Check modules for valid signatures upon load: the signature
>> +is simply appended to the module.
>> +
>> +
>> +CONFIG_MODULE_SIG_ALL=y
>> +~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +Sign all modules during make modules_install. Without this option,
>> +modules must be signed manually, using the scripts/sign-file tool.
>> +
>> +
>> +CONFIG_MODULE_SIG_FORCE=n
>> +~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +Reject unsigned modules or signed modules for which we don't have a
>> +key. Without this, such modules will simply taint the kernel.
>> +
>> +
>> +CONFIG_MODULE_SIG_FORCE=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** Self-protection
>> +
>> +Reject unsigned modules or signed modules for which we don't have a
>> +key. Without this, such modules will simply taint the kernel.
>> +
>> +
>> +CONFIG_MODULE_SIG_HASH="sha512"
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +This determines which sort of hashing algorithm will be used during
>> +signature generation.
>> +
>> +
>> +CONFIG_MODULE_SIG_SHA512=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +This determines which sort of hashing algorithm will be used during
>> +signature generation.
>> +
>> +
>> +CONFIG_PAGE_POISONING=y
>> +~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** Self-protection
>> +
>> +Fill the pages with poison patterns after free_pages() and verify
>> +the patterns before alloc_pages. The filling of the memory helps
>> +reduce the risk of information leaks from freed data. This does
>> +have a potential performance impact.
>> +Needs "page_poison=1" command line.
>> +
>> +
>> +CONFIG_PAGE_POISONING_NO_SANITY=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** Self-protection
>> +
>> +Skip the sanity checking on alloc, only fill the pages with
>> +poison on free. This reduces some of the overhead of the
>> +poisoning feature.
>> +
>> +
>> +CONFIG_PAGE_POISONING_NO_SANITY=n
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Self-protection
>> +
>> +Skip the sanity checking on alloc, only fill the pages with
>> +poison on free. This reduces some of the overhead of the
>> +poisoning feature.
>> +
>> +
>> +CONFIG_PAGE_POISONING_ZERO=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** Self-protection
>> +
>> +Instead of using the existing poison value, fill the pages with
>> +zeros. This makes it harder to detect when errors are occurring
>> +due to sanitization but the zeroing at free means that it is
>> +no longer necessary to write zeros when GFP_ZERO is used on
>> +allocation.
>> +
>> +
>> +CONFIG_PAGE_TABLE_ISOLATION=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>
> Oof. This needs to always be on... but it does have a high cost.

Yes :(

>> +**- Protection type:** Self-protection
>> +
>> +This feature reduces the number of hardware side channels by
>> +ensuring that the majority of kernel addresses are not mapped
>> +into userspace.
>> +
>> +See Documentation/x86/pti.txt for more details.
>> +
>> +
>> +CONFIG_PANIC_ON_OOPS=y
>> +~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Self-protection
>> +
>> +Say Y here to enable the kernel to panic when it oopses. This
>> +has the same effect as setting oops=panic on the kernel command
>> +line.
>> +
>> +
>> +CONFIG_PANIC_TIMEOUT=-1
>> +~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Self-protection
>> +
>> +Set the timeout value (in seconds) until a reboot occurs when the
>> +the kernel panics. If n = 0, then we wait forever. A timeout
>> +value n > 0 will wait n seconds before rebooting, while a timeout
>> +value n < 0 will reboot immediately.
>> +
>> +
>> +CONFIG_PROC_KCORE=n
>> +~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Self-protection
>> +
>> +Provides a virtual ELF core file of the live kernel. This can
>> +be read with gdb and other ELF tools, exposing kernel layout.
>> +
>> +
>> +CONFIG_PROFILING=n
>> +~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>> +**- Protection type:** Attack surface reduction
>> +
>> +Enable the extended profiling support mechanisms used
>> +by profilers such as OProfile.
>> +
>> +
>> +CONFIG_RANDOMIZE_BASE=y
>> +~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +Randomizes the physical and virtual address at which the
>> +kernel image is loaded, as a security feature that
>> +deters exploit attempts relying on knowledge of the location
>> +of kernel internals.
>> +
>> +
>> +CONFIG_RANDOMIZE_MEMORY=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +Randomizes the base virtual address of kernel memory sections
>> +(physical memory mapping, vmalloc & vmemmap). This security feature
>> +makes exploits relying on predictable memory locations less reliable.
>> +
>> +
>> +CONFIG_REFCOUNT_FULL=y
>> +~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>
> I'd put this Medium. Though some architectures use this by default (arm64, arm).

Agreed.

>> +**- Protection type:** Self-protection
>> +
>> +Enabling this switches the refcounting infrastructure from a fast
>> +unchecked atomic_t implementation to a fully state checked
>> +implementation, which can be (slightly) slower but provides protections
>> +against various use-after-free conditions that can be used in
>> +security flaw exploits.
>> +
>> +
>> +CONFIG_RETPOLINE=y
>> +~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** Self-protection
>> +
>> +Compile kernel with the retpoline compiler options to guard against
>> +kernel-to-user data leaks by avoiding speculative indirect
>> +branches. Requires a compiler with -mindirect-branch=thunk-extern
>> +support for full protection. The kernel may run slower.
>> +
>> +Without compiler support, at least indirect branches in assembler
>> +code are eliminated. Since this includes the syscall entry path,
>> +it is not entirely pointless.
>> +
>> +
>> +CONFIG_SCHED_STACK_END_CHECK=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +This option checks for a stack overrun on calls to schedule().
>> +If the stack end location is found to be over written always panic as
>> +the content of the corrupted region can no longer be trusted.
>> +This is to ensure no erroneous behaviour occurs which could result in
>> +data corruption or a sporadic crash at a later stage once the region
>> +is examined. The runtime overhead introduced is minimal.
>> +
>> +
>> +CONFIG_SECCOMP=y
>> +~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** User space protection / Attack surface reduction
>> +
>> +This kernel feature is useful for number crunching applications
>> +that may need to compute untrusted bytecode during their
>> +execution.
>> +
>> +
>> +CONFIG_SECCOMP_FILTER=y
>> +~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** User space protection / Attack surface reduction
>> +
>> +Enable tasks to build secure computing environments defined
>> +in terms of Berkeley Packet Filter programs which implement
>> +task-defined system call filtering polices.
>> +
>> +See Documentation/prctl/seccomp_filter.txt for details.
>> +
>> +
>> +CONFIG_SECURITY=y
>> +~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Generic
>> +
>> +This allows you to choose different security modules to be
>> +configured into your kernel.
>> +
>> +
>> +CONFIG_SECURITY_DMESG_RESTRICT=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** Self-protection
>> +
>> +This enforces restrictions on unprivileged users reading the kernel
>> +syslog via dmesg(8).
>> +
>> +
>> +CONFIG_SECURITY_SELINUX_DISABLE=n
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Generic
>> +
>> +This option enables writing to a selinuxfs node 'disable', which
>> +allows SELinux to be disabled at runtime prior to the policy load.
>> +SELinux will then remain disabled until the next boot.
>> +
>> +
>> +CONFIG_SECURITY_YAMA=y
>> +~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** User space protection
>> +
>> +This selects Yama, which extends DAC support with additional
>> +system-wide security settings beyond regular Linux discretionary
>> +access controls. Currently available is ptrace scope restriction.
>> +
>> +
>> +CONFIG_SLAB_FREELIST_HARDENED=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>
> I think this is Low.

Agreed.

>> +**- Protection type:** Self-protection
>> +
>> +Many kernel heap attacks try to target slab cache metadata and
>> +other infrastructure. This options makes minor performance
>> +sacrifies to harden the kernel slab allocator against common
>> +freelist exploit methods.
>> +
>> +
>> +CONFIG_SLAB_FREELIST_RANDOM=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>
> Low

OK

>> +**- Protection type:** Self-protection
>> +
>> +Randomizes the freelist order used on creating new pages. This
>> +security feature reduces the predictability of the kernel slab
>> +allocator against heap overflows.
>> +
>> +
>> +CONFIG_SLUB_DEBUG=y
>> +~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>
> This should be Low, since it doesn't actually do anything until you
> enable features on the cmdline.

Ah, right.

>> +**- Protection type:** Self-protection
>> +
>> +Enalbe SLUB debug support features.
>> +
>> +
>> +CONFIG_SLUB_DEBUG_ON=y
>> +~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** Self-protection
>> +
>> +Boot with debugging on by default. SLUB debugging may be switched
>> +off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
>> +"slub_debug=-".
>> +
>> +
>> +CONFIG_STATIC_USERMODEHELPER=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Extreme
>
> I mean, this SHOULD be Low but no distro has actually implemented a
> helper to do this yet.

Infact I set it as extreme because I expect very few people to make an
use of it.
Maybe I could just drop it.

>> +**- Protection type:** Attack surface reduction
>> +
>> +By default, the kernel can call many different userspace
>> +binary programs through the "usermode helper" kernel
>> +interface.  Some of these binaries are statically defined
>> +either in the kernel code itself, or as a kernel configuration
>> +option.  However, some of these are dynamically created at
>> +runtime, or can be modified after the kernel has started up.
>> +To provide an additional layer of security, route all of these
>> +calls through a single executable that can not have its name
>> +changed.
>> +
>> +Note, it is up to this single binary to then call the relevant
>> +"real" usermode helper binary, based on the first argument
>> +passed to it.  If desired, this program can filter and pick
>> +and choose what real programs are called.
>> +
>> +If you wish for all usermode helper programs are to be
>> +disabled, choose this option and then set
>> +STATIC_USERMODEHELPER_PATH to an empty string.
>> +
>> +
>> +CONFIG_STRICT_DEVMEM=y
>
> I feel like this should be near IO_DEVMEM and DEVMEM

I put them in alphabetical order for my convenience, but I understand
why you want them together.
Agreed.

>
>> +~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +If this option is disabled, you allow userspace (root) access
>> +to all of memory, including kernel and userspace memory.
>> +Accidental access to this is obviously disastrous, but specific
>> +access can be used by people debugging the kernel.
>> +If this option is switched on, the /dev/mem file only allows
>> +userspace access to memory mapped peripherals.
>> +
>> +
>> +CONFIG_STRICT_KERNEL_RWX=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +Kernel text and rodata memory will be made read-only, and non-text memory will
>> +be made non-executable. This provides protection against certain security
>> +exploits (e.g. executing the heap or modifying text).
>> +These features are considered standard security practice these days.
>> +
>> +
>> +CONFIG_STRICT_MODULE_RWX=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +If this is set, module text and rodata memory will be made read-only,
>> +and non-text memory will be made non-executable. This provides
>> +protection against certain security exploits (e.g. writing to text)
>> +
>> +
>> +CONFIG_SYN_COOKIES=y
>> +~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** User space protection
>> +
>> +Normal TCP/IP networking is open to an attack known as "SYN flooding".
>> +This denial-of-service attack prevents legitimate remote users from being
>> +able to connect to your computer during an ongoing attack and requires very
>> +little work from the attacker, who can operate from anywhere on the Internet.
>> +SYN cookies provide protection against this type of attack.
>> +SYN cookies may prevent correct error reporting on clients when the server is
>> +really overloaded. If this happens frequently better turn them off.
>> +Note that SYN cookies aren't enabled by default; you can enable them by saying
>> +Y to "/proc file system support" and "Sysctl support" below and executing the
>> +command:
>> +
>> +echo 1 >/proc/sys/net/ipv4/tcp_syncookies
>> +
>> +at boot time after the /proc file system has been mounted.
>> +
>> +
>> +CONFIG_THREAD_INFO_IN_TASK=y
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +Move thread_info off the stack into task_struct.
>> +
>> +
>> +CONFIG_UPROBES=n
>> +~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** High
>> +**- Protection type:** User space protection
>> +
>> +Uprobes is the user-space counterpart to kprobes: they
>> +enable instrumentation applications (such as 'perf probe')
>> +to establish unintrusive probes in user-space binaries and
>> +libraries, by executing handler functions when the probes
>> +are hit by user-space applications.
>> +
>> +
>> +CONFIG_USER_NS=n
>> +~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>
> Unfortunately I think this is High or Extreme. USER_NS gets a lot of use.

Yes, you are right.

>> +**- Protection type:** Attack surface reduction
>> +
>> +This allows containers to use user namespaces to provide different
>> +user info for different servers.
>> +User namespaces have been abused in the past for privilege
>> +escalation.
>> +
>> +
>> +CONFIG_VMAP_STACK=y
>> +~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Low
>> +**- Protection type:** Self-protection
>> +
>> +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.
>> +
>> +
>> +CONFIG_X86_SMAP=y
>> +~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>
> This is Low.

OK

>> +**- Protection type:** Self-protection
>> +
>> +Supervisor Mode Access Prevention (SMAP) is a security feature in newer
>> +Intel processors. There is a small performance cost if this enabled and
>> +turned on; there is also a small increase in the kernel size if this is
>> +enabled.
>> +
>> +
>> +CONFIG_X86_INTEL_MPX=y
>> +~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>> +**- Protection type:** User space protection
>
> No idea what to do with this one. Support is being removed, etc.
>
>> +
>> +MPX provides hardware features that can be used in conjunction with
>> +compiler-instrumented code to check memory references. It is designed
>> +to detect buffer overflow or underflow bugs.
>> +This option enables running applications which are instrumented or
>> +otherwise use MPX. It does not use MPX itself inside the kernel or to
>> +protect the kernel against bad memory references.
>> +
>> +
>> +CONFIG_X86_INTEL_UMIP=y
>> +~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +**Negative side effects level:** Medium
>
> Low?

OK

>> +**- Protection type:** Information leak prevention
>> +
>> +The User Mode Instruction Prevention (UMIP) is a security feature in newer
>> +Intel processors. If enabled, a general protection fault is issued if the
>> +SGDT, SLDT, SIDT, SMSW or STR instructions are executed in user mode.
>> +These instructions unnecessarily expose information about the hardware state.
>> +The vast majority of applications do not use these instructions. For the very
>> +few that do, software emulation is provided in specific cases in protected and
>> +virtual-8086 modes. Emulated results are dummy.
>> diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst
>> index 85492bf..01b8265 100644
>> --- a/Documentation/security/index.rst
>> +++ b/Documentation/security/index.rst
>> @@ -13,3 +13,4 @@ Security Documentation
>>     SELinux-sctp
>>     self-protection
>>     tpm/index
>> +   hardenedconfig
>> diff --git a/Makefile b/Makefile
>> index a89d8a0..e967504 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1282,7 +1282,11 @@ MRPROPER_FILES += .config .config.old .version \
>>                   Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
>>                   signing_key.pem signing_key.priv signing_key.x509     \
>>                   x509.genkey extra_certificates signing_key.x509.keyid \
>> -                 signing_key.x509.signer vmlinux-gdb.py
>> +                 signing_key.x509.signer vmlinux-gdb.py        \
>> +                 kernel/configs/hardenedlow.config     \
>> +                 kernel/configs/hardenedmedium.config  \
>> +                 kernel/configs/hardenedhigh.config    \
>> +                 kernel/configs/hardenedextreme.config
>>
>>  # clean - Delete most, but leave enough to build external modules
>>  #
>> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
>> index a3ac2c9..b5ebb13 100644
>> --- a/scripts/kconfig/Makefile
>> +++ b/scripts/kconfig/Makefile
>> @@ -100,6 +100,16 @@ endif
>>
>>  configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/configs/$@)
>>
>> +hardened%.config:
>> +       $(srctree)/scripts/kconfig/build_hardened_fragment.sh \
>
> I think this needs explicit execution (as you do a few lines later) with:
>
>     $(CONFIG_SHELL) $(srctree)/scripts/kconfig/build_hardened_fragment.sh \
> ...
>
> since the execute bit regularly gets lost in vcs, bundles, etc.

Ah yes, thank you.

>
>> +       $* $(srctree)/Documentation/security/hardenedconfig.rst > \
>> +       $(srctree)/kernel/configs/hardened$*.config
>> +       $(eval configfiles += $(srctree)/kernel/configs/hardened$*.config)
>> +
>> +       $(if $(call configfiles),, $(error No configuration exists for this target on this architecture))
>> +       $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m .config $(configfiles)
>> +       +$(Q)yes "" | $(MAKE) -f $(srctree)/Makefile oldconfig
>> +
>>  %.config: $(obj)/conf
>>         $(if $(call configfiles),, $(error No configuration exists for this target on this architecture))
>>         $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m .config $(configfiles)
>> @@ -117,6 +127,16 @@ PHONY += tinyconfig
>>  tinyconfig:
>>         $(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config
>>
>> +PHONY += hardenedlowconfig hardenedmediumconfig hardenedhighconfig hardenedextremeconfig
>> +hardenedlowconfig: hardenedlow.config
>> +       @:
>> +hardenedmediumconfig: hardenedmedium.config
>> +       @:
>> +hardenedhighconfig: hardenedhigh.config
>> +       @:
>> +hardenedextremeconfig: hardenedextreme.config
>> +       @:
>> +
>>  # CHECK: -o cache_dir=<path> working?
>>  PHONY += testconfig
>>  testconfig: $(obj)/conf
>> @@ -127,28 +147,36 @@ clean-dirs += tests/.cache
>>
>>  # Help text used by make help
>>  help:
>> -       @echo  '  config          - Update current config utilising a line-oriented program'
>> -       @echo  '  nconfig         - Update current config utilising a ncurses menu based program'
>> -       @echo  '  menuconfig      - Update current config utilising a menu based program'
>> -       @echo  '  xconfig         - Update current config utilising a Qt based front-end'
>> -       @echo  '  gconfig         - Update current config utilising a GTK+ based front-end'
>> -       @echo  '  oldconfig       - Update current config utilising a provided .config as base'
>> -       @echo  '  localmodconfig  - Update current config disabling modules not loaded'
>> -       @echo  '  localyesconfig  - Update current config converting local mods to core'
>> -       @echo  '  defconfig       - New config with default from ARCH supplied defconfig'
>> -       @echo  '  savedefconfig   - Save current config as ./defconfig (minimal config)'
>> -       @echo  '  allnoconfig     - New config where all options are answered with no'
>> -       @echo  '  allyesconfig    - New config where all options are accepted with yes'
>> -       @echo  '  allmodconfig    - New config selecting modules when possible'
>> -       @echo  '  alldefconfig    - New config with all symbols set to default'
>> -       @echo  '  randconfig      - New config with random answer to all options'
>> -       @echo  '  listnewconfig   - List new options'
>> -       @echo  '  olddefconfig    - Same as oldconfig but sets new symbols to their'
>> -       @echo  '                    default value without prompting'
>> -       @echo  '  kvmconfig       - Enable additional options for kvm guest kernel support'
>> -       @echo  '  xenconfig       - Enable additional options for xen dom0 and guest kernel support'
>> -       @echo  '  tinyconfig      - Configure the tiniest possible kernel'
>> -       @echo  '  testconfig      - Run Kconfig unit tests (requires python3 and pytest)'
>
> Can these whitespace changes be avoided?

Yes, well I like the result more, but maybe it makes less obvious what
I'm changing.

>> +       @echo  '  config                - Update current config utilising a line-oriented program'
>> +       @echo  '  nconfig               - Update current config utilising a ncurses menu based program'
>> +       @echo  '  menuconfig            - Update current config utilising a menu based program'
>> +       @echo  '  xconfig               - Update current config utilising a Qt based front-end'
>> +       @echo  '  gconfig               - Update current config utilising a GTK+ based front-end'
>> +       @echo  '  oldconfig             - Update current config utilising a provided .config as base'
>> +       @echo  '  localmodconfig        - Update current config disabling modules not loaded'
>> +       @echo  '  localyesconfig        - Update current config converting local mods to core'
>> +       @echo  '  defconfig             - New config with default from ARCH supplied defconfig'
>> +       @echo  '  savedefconfig         - Save current config as ./defconfig (minimal config)'
>> +       @echo  '  allnoconfig           - New config where all options are answered with no'
>> +       @echo  '  allyesconfig          - New config where all options are accepted with yes'
>> +       @echo  '  allmodconfig          - New config selecting modules when possible'
>> +       @echo  '  alldefconfig          - New config with all symbols set to default'
>> +       @echo  '  randconfig            - New config with random answer to all options'
>> +       @echo  '  listnewconfig         - List new options'
>> +       @echo  '  olddefconfig          - Same as oldconfig but sets new symbols to their'
>> +       @echo  '                          default value without prompting'
>> +       @echo  '  kvmconfig             - Enable additional options for kvm guest kernel support'
>> +       @echo  '  xenconfig             - Enable additional options for xen dom0 and guest kernel support'
>> +       @echo  '  tinyconfig            - Configure the tiniest possible kernel'
>> +       @echo  '  testconfig            - Run Kconfig unit tests (requires python3 and pytest)'
>> +       @echo  '  hardenedlowconfig     - Update current config using hardened features with'
>> +       @echo  '                          few negative side effects'
>> +       @echo  '  hardenedmediumconfig  - Update current config using hardened features with'
>> +       @echo  '                          some negative side effects'
>> +       @echo  '  hardenedhighconfig    - Update current config using hardened features with'
>> +       @echo  '                          many negative side effects'
>> +       @echo  '  hardenedextremeconfig - Update current config using hardened features with'
>> +       @echo  '                          even more negative side effects'
>>
>>  # ===========================================================================
>>  # Shared Makefile for the various kconfig executables:
>> diff --git a/scripts/kconfig/build_hardened_fragment.sh b/scripts/kconfig/build_hardened_fragment.sh
>> new file mode 100755
>> index 0000000..92c589a
>> --- /dev/null
>> +++ b/scripts/kconfig/build_hardened_fragment.sh
>> @@ -0,0 +1,54 @@
>> +#!/bin/sh
>> +# SPDX-License-Identifier: GPL-2.0
>> +#
>> +#  build_hardened_fragment.sh - Generate a config fragment from an .rst
>> +#  file for the specified level.
>> +#
>> +#  Copyright 2018 Salvatore Mesoraca <s.mesoraca16@gmail.com>
>> +#
>> +#  This program is free software; you can redistribute it and/or modify
>> +#  it under the terms of the GNU General Public License version 2 as
>> +#  published by the Free Software Foundation.
>> +#
>> +#  This program is distributed in the hope that it will be useful,
>> +#  but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> +#  See the GNU General Public License for more details.
>> +
>> +usage() {
>> +       echo "Usage: $0 <level> <file.rst>"
>> +       echo "Level must be one of: low, medium, high, extreme."
>
> I would send these to stderr:   >&2

Agreed.

>> +       exit 1
>> +}
>> +
>> +if [ "$#" -ne 2 ]; then
>> +       usage
>> +fi
>> +
>> +LEVEL="$(echo $1 | tr [A-Z] [a-z])"
>> +INPUT="$2"
>> +
>> +if [ "$LEVEL" != "low" ] && \
>> +   [ "$LEVEL" != "medium" ] && \
>> +   [ "$LEVEL" != "high" ] && \
>> +   [ "$LEVEL" != "extreme" ]; then
>> +       usage
>> +fi
>> +
>> +if ! [ -f "$INPUT" ]; then
>> +       usage
>> +fi
>> +
>> +if [ "$LEVEL" = "medium" ]; then
>> +       LEVEL="(low|medium)"
>> +elif [ "$LEVEL" = "high" ]; then
>> +       LEVEL="(low|medium|high)"
>> +elif [ "$LEVEL" = "extreme" ]; then
>> +       LEVEL="(low|medium|high|extreme)"
>> +fi
>> +
>> +egrep -B3 -i "^\*\*Negative side effects level:\*\* $LEVEL$" "$INPUT" | \
>> +grep "^CONFIG_" | \
>> +sed 's/^\(.*\)=[nN]/# \1 is not set/'
>> +
>> +exit 0
>> --
>> 1.9.1
>>
>
> Cool! I think being able to point into this document from the
> self-protection.rst will be nice.

Thank you very very much for taking the time to look at this very long patch!

Salvatore
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kconfig: add hardened defconfig helpers

[Kees Cook]

On Mon, Jul 30, 2018 at 9:11 AM, Salvatore Mesoraca
<s.mesoraca16@gmail.com> wrote:
> I'm sorry for the late response, I've been unexpectedly busy in the last week.
>
> 2018-07-20 7:15 GMT+02:00 Kees Cook <keescook@chromium.org>:
>> +lkml, Masahiro, and linux-doc, just for wider review/thoughts.
>>
>> On Wed, Jul 18, 2018 at 10:38 AM, Salvatore Mesoraca
>> <s.mesoraca16@gmail.com> wrote:
>> [...]
>>> +CONFIG_CC_STACKPROTECTOR_STRONG=y
>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> +
>>> +**Negative side effects level:** Medium
>>> +**- Protection type:** Self-protection
>>> +
>>> +Functions will have the stack-protector canary logic added in any
>>> +of the following conditions:
>>> +
>>> +- local variable's address used as part of the right hand side of an
>>> +assignment or function argument
>>> +- local variable is an array (or union containing an array),
>>> +regardless of array type or length
>>> +- uses register local variables
>>> +
>>> +This feature requires gcc version 4.9 or above, or a distribution
>>> +gcc with the feature backported ("-fstack-protector-strong").
>>> +
>>> +On an x86 "defconfig" build, this feature adds canary checks to
>>> +about 20% of all kernel functions, which increases the kernel code
>>> +size by about 2%.
>>
>> bikeshed: I think both stack protector items should be "Low", but
>> that's just me.
>
> I tried to be cautious when selecting the levels, but if nobody is
> against it, I can change the level.

My thought about the "Low" stuff was: if a distro has it enabled by
default, it must have been decided it was a sane default. So for
things that distros have enabled, set it to "Low" here. (Which is why
I cringed with KPTI: distros have it, but wow does it hurt...)

>>> [...]
>>> +CONFIG_DEVMEM=n
>>> +~~~~~~~~~~~~~~~
>>> +
>>> +**Negative side effects level:** Extreme
>>
>> Why is this extreme?
>
> I tried to be very cautious and I had the impression that this option
> could break many programs,
> isn't Xorg one of these?

These days, (almost?) all graphics drivers run without needing
userspace access to these things (and I think they never needed _RAM_
access, just IO space). Setting this to Medium or High seems better to
me. (The STRICT_DEVMEM, though, should be Low, since that's been a
distro setting forever.)

>> [...]
>>> +CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y
>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> +
>>> +**Negative side effects level:** High
>>> +**- Protection type:** Self-protection
>>> +
>>> +With this pluging, the kernel will instrument some kernel code to
>>> +extract some entropy from both original and artificially created
>>> +program state. This will help especially embedded systems where
>>> +there is little 'natural' source of entropy normally.  The cost
>>> +is some slowdown of the boot process (about 0.5%) and fork and
>>
>> This doesn't feel like "high" to me.
>
> Medium maybe?

Sounds good.

>> [...]
>>> +CONFIG_PAGE_POISONING=y
>>> +~~~~~~~~~~~~~~~~~~~~~~~
>>> +
>>> +**Negative side effects level:** High
>>> +**- Protection type:** Self-protection
>>> +
>>> +Fill the pages with poison patterns after free_pages() and verify
>>> +the patterns before alloc_pages. The filling of the memory helps
>>> +reduce the risk of information leaks from freed data. This does
>>> +have a potential performance impact.
>>> +Needs "page_poison=1" command line.
>>> +
>>> +
>>> +CONFIG_PAGE_POISONING_NO_SANITY=y
>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> +
>>> +**Negative side effects level:** High
>>> +**- Protection type:** Self-protection
>>> +
>>> +Skip the sanity checking on alloc, only fill the pages with
>>> +poison on free. This reduces some of the overhead of the
>>> +poisoning feature.

So, I spent some time looking at these again for unrelated reasons and
rediscovered that enable CONFIG_PAGE_POISONING has virtual zero
overhead since the actual poisoning doesn't happen unless you turn it
on with a command line argument. So I would classify both of these as
"Low".

>>> +CONFIG_PAGE_POISONING_NO_SANITY=n
>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> +
>>> +**Negative side effects level:** Extreme
>>> +**- Protection type:** Self-protection
>>> +
>>> +Skip the sanity checking on alloc, only fill the pages with
>>> +poison on free. This reduces some of the overhead of the
>>> +poisoning feature.

This one, though, yes, Extreme or High. It makes things much slower.

>>> +CONFIG_PAGE_POISONING_ZERO=y
>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> +
>>> +**Negative side effects level:** High
>>> +**- Protection type:** Self-protection
>>> +
>>> +Instead of using the existing poison value, fill the pages with
>>> +zeros. This makes it harder to detect when errors are occurring
>>> +due to sanitization but the zeroing at free means that it is
>>> +no longer necessary to write zeros when GFP_ZERO is used on
>>> +allocation.

This one is interesting: enabling it with poisoning means you gain
back some of the performance hit (since now GFP_ZERO allocations don't
need to do any work: the space was already freed), but you lose a bit
of coverage since a write-after-free will not get zeroed at allocation
time. So I think I would set this as:

CONFIG_PAGE_POISONING_ZERO=y
at Low

CONFIG_PAGE_POISONING_ZERO=n
at High (or Medium?)

>> [...]
>>> +CONFIG_STATIC_USERMODEHELPER=y
>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> +
>>> +**Negative side effects level:** Extreme
>>
>> I mean, this SHOULD be Low but no distro has actually implemented a
>> helper to do this yet.
>
> Infact I set it as extreme because I expect very few people to make an
> use of it.
> Maybe I could just drop it.

Until it's actually usable, yeah, I'd say drop it.

> [...]
> Thank you very very much for taking the time to look at this very long patch!

You're welcome! Thanks for _writing_ it. :)

-Kees

-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] kconfig: add hardened defconfig helpers

[Salvatore Mesoraca]

2018-07-30 18:54 GMT+02:00 Kees Cook <keescook@chromium.org>:
> On Mon, Jul 30, 2018 at 9:11 AM, Salvatore Mesoraca
> <s.mesoraca16@gmail.com> wrote:
>> I'm sorry for the late response, I've been unexpectedly busy in the last week.
>>
>> 2018-07-20 7:15 GMT+02:00 Kees Cook <keescook@chromium.org>:
>>> +lkml, Masahiro, and linux-doc, just for wider review/thoughts.
>>>
>>> On Wed, Jul 18, 2018 at 10:38 AM, Salvatore Mesoraca
>>> <s.mesoraca16@gmail.com> wrote:
>>> [...]
>>>> +CONFIG_CC_STACKPROTECTOR_STRONG=y
>>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> +
>>>> +**Negative side effects level:** Medium
>>>> +**- Protection type:** Self-protection
>>>> +
>>>> +Functions will have the stack-protector canary logic added in any
>>>> +of the following conditions:
>>>> +
>>>> +- local variable's address used as part of the right hand side of an
>>>> +assignment or function argument
>>>> +- local variable is an array (or union containing an array),
>>>> +regardless of array type or length
>>>> +- uses register local variables
>>>> +
>>>> +This feature requires gcc version 4.9 or above, or a distribution
>>>> +gcc with the feature backported ("-fstack-protector-strong").
>>>> +
>>>> +On an x86 "defconfig" build, this feature adds canary checks to
>>>> +about 20% of all kernel functions, which increases the kernel code
>>>> +size by about 2%.
>>>
>>> bikeshed: I think both stack protector items should be "Low", but
>>> that's just me.
>>
>> I tried to be cautious when selecting the levels, but if nobody is
>> against it, I can change the level.
>
> My thought about the "Low" stuff was: if a distro has it enabled by
> default, it must have been decided it was a sane default. So for
> things that distros have enabled, set it to "Low" here. (Which is why
> I cringed with KPTI: distros have it, but wow does it hurt...)

mmm, I think you are right.

>>>> [...]
>>>> +CONFIG_DEVMEM=n
>>>> +~~~~~~~~~~~~~~~
>>>> +
>>>> +**Negative side effects level:** Extreme
>>>
>>> Why is this extreme?
>>
>> I tried to be very cautious and I had the impression that this option
>> could break many programs,
>> isn't Xorg one of these?
>
> These days, (almost?) all graphics drivers run without needing
> userspace access to these things (and I think they never needed _RAM_
> access, just IO space). Setting this to Medium or High seems better to
> me. (The STRICT_DEVMEM, though, should be Low, since that's been a
> distro setting forever.)

Yes, agreed.

>>> [...]
>>>> +CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y
>>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> +
>>>> +**Negative side effects level:** High
>>>> +**- Protection type:** Self-protection
>>>> +
>>>> +With this pluging, the kernel will instrument some kernel code to
>>>> +extract some entropy from both original and artificially created
>>>> +program state. This will help especially embedded systems where
>>>> +there is little 'natural' source of entropy normally.  The cost
>>>> +is some slowdown of the boot process (about 0.5%) and fork and
>>>
>>> This doesn't feel like "high" to me.
>>
>> Medium maybe?
>
> Sounds good.
>
>>> [...]
>>>> +CONFIG_PAGE_POISONING=y
>>>> +~~~~~~~~~~~~~~~~~~~~~~~
>>>> +
>>>> +**Negative side effects level:** High
>>>> +**- Protection type:** Self-protection
>>>> +
>>>> +Fill the pages with poison patterns after free_pages() and verify
>>>> +the patterns before alloc_pages. The filling of the memory helps
>>>> +reduce the risk of information leaks from freed data. This does
>>>> +have a potential performance impact.
>>>> +Needs "page_poison=1" command line.
>>>> +
>>>> +
>>>> +CONFIG_PAGE_POISONING_NO_SANITY=y
>>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> +
>>>> +**Negative side effects level:** High
>>>> +**- Protection type:** Self-protection
>>>> +
>>>> +Skip the sanity checking on alloc, only fill the pages with
>>>> +poison on free. This reduces some of the overhead of the
>>>> +poisoning feature.
>
> So, I spent some time looking at these again for unrelated reasons and
> rediscovered that enable CONFIG_PAGE_POISONING has virtual zero
> overhead since the actual poisoning doesn't happen unless you turn it
> on with a command line argument. So I would classify both of these as
> "Low".

Ah, OK.

>>>> +CONFIG_PAGE_POISONING_NO_SANITY=n
>>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> +
>>>> +**Negative side effects level:** Extreme
>>>> +**- Protection type:** Self-protection
>>>> +
>>>> +Skip the sanity checking on alloc, only fill the pages with
>>>> +poison on free. This reduces some of the overhead of the
>>>> +poisoning feature.
>
> This one, though, yes, Extreme or High. It makes things much slower.
>
>>>> +CONFIG_PAGE_POISONING_ZERO=y
>>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> +
>>>> +**Negative side effects level:** High
>>>> +**- Protection type:** Self-protection
>>>> +
>>>> +Instead of using the existing poison value, fill the pages with
>>>> +zeros. This makes it harder to detect when errors are occurring
>>>> +due to sanitization but the zeroing at free means that it is
>>>> +no longer necessary to write zeros when GFP_ZERO is used on
>>>> +allocation.
>
> This one is interesting: enabling it with poisoning means you gain
> back some of the performance hit (since now GFP_ZERO allocations don't
> need to do any work: the space was already freed), but you lose a bit
> of coverage since a write-after-free will not get zeroed at allocation
> time. So I think I would set this as:
>
> CONFIG_PAGE_POISONING_ZERO=y
> at Low
>
> CONFIG_PAGE_POISONING_ZERO=n
> at High (or Medium?)

Oh, I didn't think about this. OK.

>>> [...]
>>>> +CONFIG_STATIC_USERMODEHELPER=y
>>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> +
>>>> +**Negative side effects level:** Extreme
>>>
>>> I mean, this SHOULD be Low but no distro has actually implemented a
>>> helper to do this yet.
>>
>> Infact I set it as extreme because I expect very few people to make an
>> use of it.
>> Maybe I could just drop it.
>
> Until it's actually usable, yeah, I'd say drop it.
>
>> [...]
>> Thank you very very much for taking the time to look at this very long patch!
>
> You're welcome! Thanks for _writing_ it. :)
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html