diff mbox series

[v2] kconfig: add hardened defconfig helpers

Message ID 1536516257-30871-1-git-send-email-s.mesoraca16@gmail.com (mailing list archive)
State New, archived
Headers show
Series [v2] kconfig: add hardened defconfig helpers | expand

Commit Message

Salvatore Mesoraca Sept. 9, 2018, 6:04 p.m. UTC
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 and on kconfig-hardened-check, 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.
'Extreme' level collects those protections that may have so 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.

Link: http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
Link: https://github.com/a13xp0p0v/kconfig-hardened-check
Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
---
Changes in v2:
	- Moved generated config fragments to "generated/"
	  subdirectory. (Suggested by Kees Cook)
	- Dropped CONFIG_BUG, CONFIG_DEFAULT_MMAP_MIN_ADDR,
	  CONFIG_STATIC_USERMODEHELPER,
	  CONFIG_X86_INTEL_MPX. (Suggested by Kees Cook)
	- Dropped CONFIG_THREAD_INFO_IN_TASK. (Suggested by Jann Horn)
	- Improved CONFIG_BPF_JIT description. (Suggested by Jann Horn)
	- Improved CONFIG_USER_NS description.
	  (Suggested by Eric W. Biederman)
	- Make build_hardened_fragment.sh print help to stderr.
	  (Suggested by Kees Cook)
	- Dropped whitespace only change in make help text.
	  (Suggested by Kees Cook)
	- Various changes to levels. (Suggested by Kees Cook)
	- Various changes to protection types. (Suggested by Kees Cook)
---
 .gitignore                                 |   3 +
 Documentation/security/hardenedconfig.rst  | 971 +++++++++++++++++++++++++++++
 Documentation/security/index.rst           |   1 +
 Makefile                                   |   3 +-
 scripts/kconfig/Makefile                   |  29 +
 scripts/kconfig/build_hardened_fragment.sh |  54 ++
 6 files changed, 1060 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/security/hardenedconfig.rst
 create mode 100755 scripts/kconfig/build_hardened_fragment.sh

Comments

Sam Ravnborg Sept. 9, 2018, 7:19 p.m. UTC | #1
Hi Salvatore.

On Sun, Sep 09, 2018 at 08:04:17PM +0200, Salvatore Mesoraca 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 and on kconfig-hardened-check, 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.
> 'Extreme' level collects those protections that may have so 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.

In the above you nicely describes what is done.
But there is nothing about the target group for this feature.
Who will benefit from this?

With respect to the actual implmentation we now
have two ways to handle config fragments.
Current solution is to save the config fragments in kernel/configs.
And the new solution is to parse the config fragments from an rst file.
The changelog fails to mentions why we need a new way to handle
the config fragments.

If we want to go the "parse from rst file" way - can it then
be abstracted in a way so this is the only way to handle
these in-kernel config fragments?
And then move the current config fragment to the new way.

It most be possible with a little careful design to make this
a general solution and not a hardening thing only.

	Sam
Jonathan Corbet Sept. 9, 2018, 8:27 p.m. UTC | #2
On Sun,  9 Sep 2018 20:04:17 +0200
Salvatore Mesoraca <s.mesoraca16@gmail.com> wrote:

> +===============================
> +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``).

Some overall thoughts:

- As Sam asked: who are the users of this feature?  Presumably you have
  some real people out there in mind for each of these levels, or you would
  not have created them?

- Who will maintain it?  The list of hardening-relevant configuration
  options is always in high flux, as our understanding of the security
  implications of each.  This feature will require some significant ongoing
  attention or it will quickly become stale.  I think it needs a
  MAINTAINERS entry.

- It's a little strange to see an RST document used as the input for the
  kernel configuration process.  Assuming this is really the best way to do
  this (and I worry about things like duplicated descriptions of kernel
  configuration options), you should, at a minimum, carefully document the
  format of this file at the beginning.  Otherwise people will surely break
  it.  In fact, they'll break it anyway, so more checking in the processing
  script seems indicated.

  Without having thought it through in great depth, I suspect that a better
  approach might be to find a way to mark the hardening level in the
  Kconfig entries.

- You have ordered the options alphabetically, but that is, I would argue,
  not the best way.  My guess is that people would read this file to answer
  the question of "just how many bullets will hardening level H put into my
  foot?"  So I would sort them by hardening level as the primary key.

Thanks,

jon
Masahiro Yamada Sept. 10, 2018, 1:21 a.m. UTC | #3
2018-09-10 4:19 GMT+09:00 Sam Ravnborg <sam@ravnborg.org>:
> Hi Salvatore.
>
> On Sun, Sep 09, 2018 at 08:04:17PM +0200, Salvatore Mesoraca 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 and on kconfig-hardened-check, 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.
>> 'Extreme' level collects those protections that may have so 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.
>
> In the above you nicely describes what is done.
> But there is nothing about the target group for this feature.
> Who will benefit from this?
>
> With respect to the actual implmentation we now
> have two ways to handle config fragments.
> Current solution is to save the config fragments in kernel/configs.
> And the new solution is to parse the config fragments from an rst file.
> The changelog fails to mentions why we need a new way to handle
> the config fragments.


I agree.

Another new way this patch added is,

 CONFIG options are now described in the ReST document,
 but our current way is to describe the detailed information
 in the 'help' section in Kconfig files.






> If we want to go the "parse from rst file" way - can it then
> be abstracted in a way so this is the only way to handle
> these in-kernel config fragments?
> And then move the current config fragment to the new way.
>
> It most be possible with a little careful design to make this
> a general solution and not a hardening thing only.
>
>         Sam


Indeed.  The file format is too specific for his purpose;
'Negative side effect level' is a key word
that must be placed 3 lines below the CONFIG entry.
Salvatore Mesoraca Sept. 16, 2018, 5:14 p.m. UTC | #4
Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Salvatore.

Hi Sam

> On Sun, Sep 09, 2018 at 08:04:17PM +0200, Salvatore Mesoraca 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 and on kconfig-hardened-check, 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.
> > 'Extreme' level collects those protections that may have so 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.
>
> In the above you nicely describes what is done.
> But there is nothing about the target group for this feature.
> Who will benefit from this?

Sometimes people ask about kernel hardening features, that's the
reason why the KSPP's list and the kconfig-hardened-check script were
written.
Unfortunately, kernel features with security implications have often
misleading names and descriptions and are scattered around the
menuconfig.
This patchset will help anyone who want to have an "hardened kernel"
but isn't following kernel development closely enough to know about
all the features.
On one hand, this will provide an official and understandable list of
hardening features inside the kernel doc, on the other hand it also
provide a fast and easy way to enable those features all at once.

> With respect to the actual implmentation we now
> have two ways to handle config fragments.
> Current solution is to save the config fragments in kernel/configs.
> And the new solution is to parse the config fragments from an rst file.
> The changelog fails to mentions why we need a new way to handle
> the config fragments.

The reason why I'm doing it like this is that I want both the config
fragments and the doc in the kernel.
Generating the fragments from the doc is the best way to make sure
that they will always do what the doc says.

> If we want to go the "parse from rst file" way - can it then
> be abstracted in a way so this is the only way to handle
> these in-kernel config fragments?
> And then move the current config fragment to the new way.
>
> It most be possible with a little careful design to make this
> a general solution and not a hardening thing only.

I don't know if maintainers of the other fragments care at all about
having every single option documented in detail.
For hardening features it makes sense, because people may want to just
learn about them and enable them manually.
I don't know if this is common or desirable for other config fragments.

Thank you for you comment,

Salvatore
Salvatore Mesoraca Sept. 16, 2018, 5:38 p.m. UTC | #5
Jonathan Corbet <corbet@lwn.net> wrote:
> [omissis]
>
> Some overall thoughts:
>
> - As Sam asked: who are the users of this feature?  Presumably you have
>   some real people out there in mind for each of these levels, or you would
>   not have created them?

In general this feature will be useful for all those people who are
interested in enabling hardening features on their kernel.
Maybe they are not so many, but they exist and are the reason why
KSPP's list and kconfig-hardened-check script were written.
Anyway, not everybody is willing to trade a lot of performance for security.
I hope that splitting features based on their negative impact will
increase the usage of those features which are more "usable", but
still not so known by many people.

> - Who will maintain it?  The list of hardening-relevant configuration
>   options is always in high flux, as our understanding of the security
>   implications of each.  This feature will require some significant ongoing
>   attention or it will quickly become stale.  I think it needs a
>   MAINTAINERS entry.

Good, I can add myself as maintainer, I also got Kees permission to
add him as designated reviewer too.

> - It's a little strange to see an RST document used as the input for the
>   kernel configuration process.  Assuming this is really the best way to do
>   this (and I worry about things like duplicated descriptions of kernel
>   configuration options), you should, at a minimum, carefully document the
>   format of this file at the beginning.  Otherwise people will surely break
>   it.  In fact, they'll break it anyway, so more checking in the processing
>   script seems indicated.

Yes, this approach is a bit "original". I think your suggestions are sensible.
I'll document better the format and add more checks to the script to
make it more resilient.

>   Without having thought it through in great depth, I suspect that a better
>   approach might be to find a way to mark the hardening level in the
>   Kconfig entries.

The reason why everything starts from an .rst is that I'd like to have
a doc page with a detailed list of all the hardening feature.
If the fragments aren't going to be generated from the doc we'll a way
to make sure that what is written in the doc is coherent with what
Kconfig is doing.
I'm don't think that it will be much better.

> - You have ordered the options alphabetically, but that is, I would argue,
>   not the best way.  My guess is that people would read this file to answer
>   the question of "just how many bullets will hardening level H put into my
>   foot?"  So I would sort them by hardening level as the primary key.

This seems reasonable, I'll change it.

Thank you for your time,

Salvatore
Salvatore Mesoraca Sept. 16, 2018, 5:44 p.m. UTC | #6
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
>
> 2018-09-10 4:19 GMT+09:00 Sam Ravnborg <sam@ravnborg.org>:
> > Hi Salvatore.
> >
> > On Sun, Sep 09, 2018 at 08:04:17PM +0200, Salvatore Mesoraca 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 and on kconfig-hardened-check, 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.
> >> 'Extreme' level collects those protections that may have so 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.
> >
> > In the above you nicely describes what is done.
> > But there is nothing about the target group for this feature.
> > Who will benefit from this?
> >
> > With respect to the actual implmentation we now
> > have two ways to handle config fragments.
> > Current solution is to save the config fragments in kernel/configs.
> > And the new solution is to parse the config fragments from an rst file.
> > The changelog fails to mentions why we need a new way to handle
> > the config fragments.
>
>
> I agree.
>
> Another new way this patch added is,
>
>  CONFIG options are now described in the ReST document,
>  but our current way is to describe the detailed information
>  in the 'help' section in Kconfig files.

This is true, but hardening features are quite different from other
types of features or config options, because they can't be easily
found, unless you already know what you are looking for.
Many people need a single place that lists them all, clearly
explaining why they might want them or not without having to bounce
around different Kconfig parts.

Thank you for your time,

Salvatore
diff mbox series

Patch

diff --git a/.gitignore b/.gitignore
index 97ba6b7..cbc1856 100644
--- a/.gitignore
+++ b/.gitignore
@@ -132,3 +132,6 @@  all.config
 
 # Kdevelop4
 *.kdev4
+
+# Generated config fragments
+kernel/configs/generated
diff --git a/Documentation/security/hardenedconfig.rst b/Documentation/security/hardenedconfig.rst
new file mode 100644
index 0000000..6175dd7
--- /dev/null
+++ b/Documentation/security/hardenedconfig.rst
@@ -0,0 +1,971 @@ 
+.. 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:** 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:** 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 significantly
+speedup packet sniffing (libpcap/tcpdump) and seccomp.
+
+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:** Kernel attack surface reduction
+
+Enable the bpf() system call that allows to manipulate eBPF
+programs and maps via file descriptors.
+
+
+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:** Kernel memory integrity
+
+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:** Kernel memory integrity
+
+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%.
+
+
+CONFIG_COMPAT_BRK=n
+~~~~~~~~~~~~~~~~~~~
+
+**Negative side effects level:** Low
+**- Protection type:** 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:** 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_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:** Medium
+**- Protection type:** Self-protection
+
+The /dev/mem device is used to access areas of physical
+memory.
+
+
+CONFIG_STRICT_DEVMEM=y
+~~~~~~~~~~~~~~~~~~~~~~
+
+**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_IO_STRICT_DEVMEM=y
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Negative side effects level:** Low
+**- 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_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:** Kernel attack surface reduction
+
+Enable the kernel tracing infrastructure.
+
+
+CONFIG_GCC_PLUGINS=y
+~~~~~~~~~~~~~~~~~~~~
+
+**Negative side effects level:** Low
+**- Protection type:** 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:** Medium
+**- 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
+irq processing.
+Note that entropy extracted this way is not cryptographically
+secure!
+
+
+CONFIG_GCC_PLUGIN_RANDSTRUCT=y
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Negative side effects level:** Extreme
+**- 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:** 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:** Low
+**- 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:** Medium
+**- Protection type:** Kernel memory integrity
+
+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_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:** Medium
+**- 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:** 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:** Low
+**- 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:** Low
+**- 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:** Low
+**- 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_POISONING_ZERO=n
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**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
+**- 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:** Medium
+**- 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:** 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:** 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:** Low
+**- 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_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_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:** Extreme
+**- Protection type:** Attack surface reduction
+
+This allows containers to use user namespaces to provide different
+user info for different servers.
+Correct use of user namespaces can increase security and there are
+no known issues at the time of writing.
+But they have been abused in the past for privilege escalation due
+to implementation mistakes.
+Disabling this feature, if it isn't needed, can be useful to
+reduce the attack surface.
+
+
+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:** 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_UMIP=y
+~~~~~~~~~~~~~~~~~~~~~~~
+
+**Negative side effects level:** 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 19948e5..fc6fcff 100644
--- a/Makefile
+++ b/Makefile
@@ -1311,7 +1311,8 @@  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/generated/*
 
 # clean - Delete most, but leave enough to build external modules
 #
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 67ed9f6..d4f6b2d 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -105,6 +105,17 @@  endif
 
 configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/configs/$@)
 
+hardened%.config:
+	mkdir $(srctree)/kernel/configs/generated/ || true
+	$(CONFIG_SHELL) $(srctree)/scripts/kconfig/build_hardened_fragment.sh \
+	$* $(srctree)/Documentation/security/hardenedconfig.rst > \
+	$(srctree)/kernel/configs/generated/hardened$*.config
+	$(eval configfiles += $(srctree)/kernel/configs/generated/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)
@@ -122,6 +133,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
@@ -154,6 +175,14 @@  help:
 	@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..218fb8f
--- /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>" >&2
+	echo "Level must be one of: low, medium, high, extreme." >&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