Securing your Linux Configuration (Kernel Hardening)

By: Nathan Barrett-Morrison, 2022-02-01

This article discusses the process by which your kernel's configuration can be strengthened to protect against common security exploits.
This is sometimes referred to as hardening, or specifically in this context, kernel configuration hardening.

Preface

A Linux kernel configuration is a file which defines all of the enabled (or disabled) options which are compiled in to your kernel. If you
have not seen one before, they generally reside in the kernel's build directory with a filename of ".config". They are sometimes collapsed
in to a defconfig (default config) file which only shows options which were not already selected by default.

This discussion will present many configuration tables in the form of:

Expected Conditional Architectures Kernel Versions Note

Architecture to which this option applys (X86 and/or Kernel versions in which OPTION1 A description of
OPTION1=Y
ARM) exists OPTION1

Architecture to which this option applys (X86 and/or Kernel versions in which OPTION2 A description of
OPTION2=is not set
ARM) exists OPTION2

In this case, it is recommended that the fictional option, OPTION1, is selected (CONFIG_OPTION1=y) in your kernel's .config or
defconfig file. It is also recommended that OPTION2 is disabled (CONFIG_OPTION2=is not set) in your kernel's .config or defconfig
file.

The option descriptions are sometimes difficult to interpret and may require further research. If you find an option that you'd like to know
more information about, you may have to inspect the kernel source, search LWN, search Patchwork, or use your web search engine of
choice.

Understanding Configuration Selections

When kernel hardening, there are generally four categories of reason for which a configuration item may be enabled or disabled:

Adding an additional level of protection against a known exploit by enabling a configuration item. For example:
Mitigating Spectre attacks with CONFIG_RETPOLINE=y (which traps the processor's speculative execution paths for
indirect address calls by using a return trampoline).
Disabling a configuration item or subsystem which is known to be exploitable. For example:
Disabling the USB networking subsystem (USB_USBNET=is not set), so that applications using network-based IPC(Inter-
Processor Communication) mechanisms may not be inadvertently exposed through a USB port.
Disabling /dev/mem access to physical memory (DEVMEM=is not set), so that physical memory cannot be easily modified.
Enabling general security strengthening features in the kernel (which may necessarily protect against a presently known attack).
For example:
Reducing the risk of memory page leakage by enabling page poisoning (PAGE_POISONING=Y) to overwrite any
potentially sensitive information upon freeing.
Enabling Security-Enhanced Linux
Disabling any unused kernel configuration options. If you don't need it, disable it. As an added bonus, doing so may also improve
your boot times.

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
X86_32, 4.15-4.20, 5.0-
RETPOLINE=Y Avoid speculative indirect branches in kernel (Spectre Mitigation)
X86_64 5.17

ARM, ARM64, 2.6.22-2.6.39, 3.0-

USB_USBNET=is not
X86_32, 3.19, 4.0-4.20, If enabled, this adds USB networking subsystem support to the kernel
set
X86_64 5.0-5.17

ARM, ARM64,
DEVMEM=is not set X86_32, 4.0-4.20, 5.0-5.17 Do not allow access to physical memory via /dev/mem
X86_64

Fill the pages with poison patterns after free_pages() and verify the patterns
ARM, ARM64,
before alloc_pages. The filling of the memory helps reduce the risk of
PAGE_POISONING=Y X86_32, 4.6-4.20, 5.0-5.17
information leaks from freed data. This must be enabled from the boot
X86_64
cmdline with page_poison=1

The latter two options can help to protect against exploits which have not yet been discovered or released into the public domain (e.g.
zero-day exploits) by reducing your kernel's exploitable attack surface.

Analyzing, understanding, and modifying the kernel configuration with these tasks in mind is not trivial. Furthermore, in a large project it
may not be clear exactly who is using which kernel configuration option. This can result in iterative backstepping until you arrive at a
final configuration which works for your entire team.

There's also a maintenance burden once you have created your final configuration. When you upgrade your kernel, many of the
configuration options will have been removed and renamed. This will require another assessment and configuration period. Keeping your
kernel up to date is extremely important, as security features are continuously added and revised in newer kernels. Starting a project with
a long term stable (LTS) kernel is recommended, as an LTS kernel provides smaller (and sometimes backported) version increments to
resolve security flaws (e.g upgrading from 5.0.x to 5.0.y). Such patches are provided until the long term stable support period ends.

Cost-Benefit Analysis
Not all configuration items provide the same cost-benefit as others. To some extent, most options will have an impact in these key areas:

Compile Time
This is especially true for security features which are checked by the compiler during compile time. For example,
GCC_PLUGIN_STACKLEAK=Y will block uninitialized stack variable attacks through the use of a compiler plugin which
searches for and initializes such variables.
This should not be considered a concern. Added compilation time is well worth the added security.
Kernel Binary Size
This is usually not a concern. Adding and removing features may change the kernel size by a few megabytes, which is
generally negligible on modern systems.
Boot time
For example, DM_CRYPT=y, which adds drive encryption capabilities to your kernel, will add additional non-neglibile boot
time to your system. This is because it may require booting in to an Initial Ram Filesystem, retreiving your disk encryption
key, and ultimately mounting the encrypted disk through the device mapper subsystem. All of these steps add time to the
boot process.
Processor Load
This is perhaps the most concerning option and must be determined by trial and error. If every available security option is
enabled on a slower ARM processor, there may be too much overhead to reliably run your processes (at a reasonable
latency).
For example, erasing memory with PAGE_POISONING=Y will use CPU cycles. The amount of overhead added will be
dependent upon factors such as your CPU and RAM speed.

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
This blocks most uninitialized stack variable attacks, with the
ARM64,
performance impact being driven by the depth of the stack usage,
GCC_PLUGIN_STACKLEAK=Y X86_32, 5.2-5.17
rather than the function calling complexity. The performance impact on
X86_64
a single CPU system kernel compilation sees a 1% slowdown.

ARM, ARM64, 2.6.4-2.6.39, 3.0-

Filesystem Hardening (Block Level Encryption via dm-crypt) - Requires
DM_CRYPT=Y X86_32, 3.19, 4.0-4.20,
userspace support
X86_64 5.0-5.17

Fill the pages with poison patterns after free_pages() and verify the
ARM, ARM64,
patterns before alloc_pages. The filling of the memory helps reduce
PAGE_POISONING=Y X86_32, 4.6-4.20, 5.0-5.17
the risk of information leaks from freed data. This must be enabled
X86_64
from the boot cmdline with page_poison=1

Some configuration items will provide a better cost-benefit. Configuration items which have minimal impact on processor load are most
valuable. For example, these add virtually no CPU overhead:

Disabling DEBUG_BUGVERBOSE, which will help ensure that sensitive backtrace information is not leaked upon a kernel
BUG() condition.
Enabling ARCH_HAS_ELF_RANDOMIZE, which will make repeat exploits much more difficult by randomizing certain
memory locations.

While these will add CPU overhead to some degree:

Enabling DEBUG_VIRTUAL will enable some sanity checking in virt_to_page translation at the cost of CPU cycles.
Enabling INIT_ON_ALLOC_DEFAULT_ON or INIT_ON_FREE_DEFAULT_ON will protect against heap memory leaks by
erasing the regions after use, at the cost of erase time.

Expected Conditional Architectures Kernel Versions Note

ARM, ARM64, 2.6.9-2.6.39, 3.0-
Make sure this is not enabled, as it could provide an attacker
DEBUG_BUGVERBOSE=is not set X86_32, 3.19, 4.0-4.20,
sensitive kernel backtrace information on BUG() conditions
X86_64 5.0-5.17

ARM, ARM64,
ARCH_HAS_ELF_RANDOMIZE=Y X86_32, 4.1-4.20, 5.0-5.17 Randomized locations for stack, mmap, brk, and ET_DYN
X86_64

More expensive form of INIT_ON_ALLOC_DEFAULT_ON. The

ARM, ARM64,
primary difference is that data lifetime in memory is reduced, as
INIT_ON_FREE_DEFAULT_ON=Y X86_32, 5.3-5.17
anything freed is wiped immediately, making live forensics or cold
X86_64
boot memory attacks unable to recover freed memory contents.

ARM, ARM64, All page allocator and slab allocator memory will be zeroed when
INIT_ON_ALLOC_DEFAULT_ON=Y X86_32, 5.3-5.17 freed, eliminating many kinds of "uninitialized heap memory" flaws,
X86_64 especially heap content exposures.

ARM, ARM64, 2.6.28-2.6.39, 3.0-

Enable some costly sanity checks in virtual to page code. This can
DEBUG_VIRTUAL=Y X86_32, 3.19, 4.0-4.20,
catch mistakes with virt_to_page() and friends.
X86_64 5.0-5.17

Using multiple kernel configurations (development and production) can be an option. While it is wise to develop on a prototype system
that most closely resembles a production system (as to not cause unforseen bugs in changing timing conditions and loads between
configurations), some security options be too cumbersome to reasonably develop on. If you're writing a kernel driver and you need to use
a tracing tool or read a core dump, then certainly enable them while developing.

Timesys Corporation, 2022

[Link]
Categories of Kernel Hardening

In the Timesys Kernel Hardening Analysis Tool, the kernel security options have been divided into various groups. This categorization is
by no means a definitive separation; some options could be further categorized or applied to multiple categories.

Memory Protection

Memory exploits are classes of attack in which an entity is able to retrieve or modified privileged information about the system. These
can be further categorized into:

Stack Overflow Protections: These are security features which seek to prevent access to and tampering of stack variables in
memory. A stack canary (an arbitrary value sitting at the top of the stack, which, if modified, alerts the kernel of tampering) is
sometimes mentioned in these protections.

Expected Conditional Architectures Kernel Versions Note

Initializes everything on the stack with a zero value. This is
ARM, ARM64, intended to eliminate all classes of uninitialized stack
INIT_STACK_ALL_ZERO=Y X86_32, 5.9-5.17 variable exploits and information exposures, even variables
X86_64 that were warned to have been left uninitialized. (Strongest,
safest)

Generates a separate stack canary value for each task, so if

GCC_PLUGIN_ARM_SSP_PER_TASK=Y ARM 5.2-5.17 one task's canary value is leaked it does not cause all other
tasks to become vulnerable.

This option turns on the "stack-protector" GCC feature. This

feature puts, at the beginning of functions, a canary value on
ARM, ARM64, the stack just before the return address, and validates the
4.18-4.20, 5.0-
STACKPROTECTOR=Y X86_32, value just before actually returning. Stack based buffer
5.17
X86_64 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.

ARM, ARM64,
4.18-4.20, 5.0- Adds the CONFIG_STACKPROTECTOR canary logic to
STACKPROTECTOR_STRONG=Y X86_32,
5.17 additional conditions related to variable assignment.
X86_64

STACKPROTECTOR_PER_TASK=Y ARM, ARM64 5.0-5.17 Use a different stack canary value for each task

Enable this if you want the use virtually-mapped kernel

VMAP_STACK=Y ARM64 4.9-4.20, 5.0-5.17 stacks with guard pages. This causes kernel stack overflows
to be caught immediately.

ARM, ARM64,
3.18-3.19, 4.0- Additional validation check on commonly targeted structure.
SCHED_STACK_END_CHECK=Y X86_32,
4.20, 5.0-5.17 Detect stack corruption on calls to schedule()
X86_64

ARM64,
If this is set, STACKLEAK metrics for every task are
STACKLEAK_METRICS=is not set X86_32, 5.2-5.17
available in the /proc file system.
X86_64

ARM64,
STACKLEAK_RUNTIME_DISABLE=is
X86_32, 5.2-5.17 If set, allows runtime disabling of kernel stack erasing
not set
X86_64

This blocks most uninitialized stack variable attacks, with the

ARM64, performance impact being driven by the depth of the stack
GCC_PLUGIN_STACKLEAK=Y X86_32, 5.2-5.17 usage, rather than the function calling complexity. The
X86_64 performance impact on a single CPU system kernel
compilation sees a 1% slowdown.

Timesys Corporation, 2022

[Link]
 Heap Overflow: These are security features which seek to prevent heap memory exposure and modification.

Expected Conditional Architectures Kernel Versions Note

If this is set, kernel text and rodata memory will be made read-only,
ARM, ARM64,
4.11-4.20, 5.0- and non-text memory will be made non-executable. This provides
STRICT_KERNEL_RWX=Y X86_32,
5.17 protection against certain security exploits (e.g. executing the heap
X86_64
or modifying text)

Harden slab freelist metadata: Many kernel heap attacks try to

target slab cache metadata and other infrastructure. This options
ARM, ARM64,
4.14-4.20, 5.0- makes minor performance sacrifices to harden the kernel slab
SLAB_FREELIST_HARDENED=Y X86_32,
5.17 allocator against common freelist exploit methods. Some slab
X86_64
implementations have more sanity-checking than others. This option
is most effective with CONFIG_SLUB.

ARM, ARM64, Randomizes the freelist order used on creating new pages. This
SLAB_FREELIST_RANDOM=Y X86_32, 4.7-4.20, 5.0-5.17 security feature reduces the predictability of the kernel slab allocator
X86_64 against heap overflows.

ARM, ARM64, 2.6.25-2.6.39, 3.0-

COMPAT_BRK=is not set X86_32, 3.19, 4.0-4.20, Do not disable heap randomization
X86_64 5.0-5.17

ARM, ARM64, 2.6.14-2.6.39, 3.0-

Do not allow INET socket monitoring interface. Assists heap
INET_DIAG=is not set X86_32, 3.19, 4.0-4.20,
memory attacks
X86_64 5.0-5.17

User Copy Protection: These are security features which seek to prevent memory exploitation during kernel and userspace memory
transfer transactions.

Expected Conditional Architectures Kernel Versions Note

This option checks for obviously wrong memory
regions when copying memory to/from the kernel
(via copy_to_user() and copy_from_user()
ARM, ARM64, functions) by rejecting memory ranges that are
HARDENED_USERCOPY=Y X86_32, 4.8-4.20, 5.0-5.17 larger than the specified heap object, span multiple
X86_64 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.

This is a temporary option that allows missing

usercopy whitelists to be discovered via a WARN()
ARM, ARM64,
4.16-4.20, 5.0- to the kernel log, instead of rejecting the copy,
HARDENED_USERCOPY_FALLBACK=is not set X86_32,
5.15 falling back to non-whitelisted hardened usercopy
X86_64
that checks the slab allocation size instead of the
whitelist size.

When a multi-page allocation is done without

__GFP_COMP, hardened usercopy will reject
ARM, ARM64,
attempts to copy it. There are, however, several
HARDENED_USERCOPY_PAGESPAN=is not set X86_32, 4.8-4.20, 5.0-5.17
cases of this in the kernel that have not all been
X86_64
removed. This config is intended to be used only
while trying to find such users.

ARM, ARM64, The heap allocator implements

HAVE_HARDENED_USERCOPY_ALLOCATOR=Y X86_32, 4.8-4.20, 5.0-5.17 __check_heap_object() for validating memory
X86_64 ranges against heap object sizes.

Timesys Corporation, 2022

[Link]
 Information exposure: Options which are selected to limit exposure to privileged information.

Expected Conditional Architectures Kernel Versions Note

If enabled, a general protection fault is issued if the SGDT, SLDT, SIDT,
X86_32,
X86_UMIP=Y 5.5-5.17 SMSW or STR instructions are executed in user mode. These instructions
X86_64
unnecessarily expose information about the hardware state.

ARM, ARM64, 2.6.28-2.6.39, 3.0-

PROC_PAGE_MONITOR=is
X86_32, 3.19, 4.0-4.20, Do not expose process memory utilization via /proc interfaces
not set
X86_64 5.0-5.17

ARM, ARM64, 2.6.37-2.6.39, 3.0-

PROC_VMCORE=is not set X86_32, 3.19, 4.0-4.20, Do not export the dump image of crashed kernel
X86_64 5.0-5.17

ARM, ARM64, 2.6.11-2.6.39, 3.0-

DEBUG_FS=is not set X86_32, 3.19, 4.0-4.20, Do not enable debugfs, as it may expose vulnerabilities
X86_64 5.0-5.17

Kernel Address Space Layout Randomization (KASLR): A security method by which kernel memory structures are randomized in
order to prevent repeat or replay-style attacks.

Expected Conditional Architectures Kernel Versions Note

ARM, ARM64,
ARCH_HAS_ELF_RANDOMIZE=Y X86_32, 4.1-4.20, 5.0-5.17 Randomized locations for stack, mmap, brk, and ET_DYN
X86_64

In support of Kernel Address Space Layout Randomization

ARM64, (KASLR), this randomizes the physical address at which the kernel
RANDOMIZE_BASE=Y X86_32, 4.7-4.20, 5.0-5.17 image is decompressed and the virtual address where the kernel
X86_64 image is mapped, as a security feature that deters exploit attempts
relying on knowledge of the location of kernel code internals.

Randomizes the base virtual address of kernel memory sections

(physical memory mapping, vmalloc & vmemmap). This security
RANDOMIZE_MEMORY=Y X86_64 4.8-4.20, 5.0-5.17
feature makes exploits relying on predictable memory locations less
reliable.

ARM, ARM64, Randomizes the freelist order used on creating new pages. This
SLAB_FREELIST_RANDOM=Y X86_32, 4.7-4.20, 5.0-5.17 security feature reduces the predictability of the kernel slab allocator
X86_64 against heap overflows.

ARM, ARM64,
4.13-4.20, 5.0-
GCC_PLUGIN_RANDSTRUCT=Y X86_32, Randomizes layout of sensitive kernel structures
5.17
X86_64

Timesys Corporation, 2022

[Link]
Reducing Attack Surface

These are configuration options which can be selected to reduce the potential for exposure to unknown zero-day attacks by limiting the
attack surface as much as we can. These are options that reduce the amount of information exposure and compiled-firmware attack
surface (Again: If you don't need it, disable it).

Kernel Replacement Attacks: Methods in which a kernel binary could be replaced during runtime.

Expected Conditional Architectures Kernel Versions Note

HIBERNATION=is not ARM, ARM64, X86_32, 2.6.23-2.6.39, 3.0-3.19, 4.0-4.20, Do not support hibernation. Allows replacement of
set X86_64 5.0-5.17 running kernel.

ARM, ARM64, X86_32, 2.6.16-2.6.39, 3.0-3.19, 4.0-4.20,

KEXEC=is not set Do not allow system to boot another Linux kernel
X86_64 5.0-5.17

ARM, ARM64, X86_32,

KEXEC_FILE=is not set 3.17-3.19, 4.0-4.20, 5.0-5.17 Do not allow system to boot another Linux kernel
X86_64

Module Security Attacks: These are attacks which can be performed by loading a tainted, custom, module in to a system or
maliciously modifying a pre-existing module's memory. The mitigations for this mostly consist of restricting execution regions,
making such regions read-only, and signature checking prior to loading modules.

Expected Conditional Architectures Kernel Versions Note

ARM, ARM64, You should not allow for modules to be loaded unless you have the
MODULES=is not set X86_32, proper signing and signature checks enabled. Allowing the kernel to
X86_64 load unsigned modules can be dangerous

ARM, ARM64, Module text and rodata memory will be made read-only, and non-
4.11-4.20, 5.0-
STRICT_MODULE_RWX=Y X86_32, text memory will be made non-executable. This provides protection
5.17
X86_64 against certain security exploits (e.g. writing to text)

ARM, ARM64,
3.7-3.19, 4.0-4.20,
MODULE_SIG=Y X86_32, Enable module signature verification
5.0-5.17
X86_64

ARM, ARM64,
3.9-3.19, 4.0-4.20, Automatically sign all modules during modules_install (so we don't
MODULE_SIG_ALL=Y X86_32,
5.0-5.17 have to do this manually)
X86_64

ARM, ARM64,
3.7-3.19, 4.0-4.20,
MODULE_SIG_SHA512=Y X86_32, Sign modules with SHA-512 algorithm
5.0-5.17
X86_64

ARM, ARM64,
3.7-3.19, 4.0-4.20,
MODULE_SIG_FORCE=Y X86_32, Require modules to be validly signed
5.0-5.17
X86_64

ARM, ARM64,
Varies depending Helps catch unintended modifications to loadable kernel module's
DEBUG_SET_MODULE_RONX=Y X86_32,
on architecture text and read-only data. It also prevents execution of module data.
X86_64

Timesys Corporation, 2022

[Link]
 Reducing Syscall Exposure: Syscalls are interfaces in which user-space and kernel-space can communicate and access each other.
Some legacy syscalls may be exploitable and are generally not required on modern systems. Disabling syscalls when possible is a
good way to reduce your attack surface.

Expected Conditional Architectures Kernel Versions Note

This kernel feature is useful for number crunching applications that
may need to compute untrusted bytecode during their execution. By
using pipes or other transports made available to the process as file
ARM, ARM64,
Varies depending descriptors supporting the read/write syscalls, it's possible to isolate
SECCOMP=Y X86_32,
on architecture those applications in their own address space using seccomp. Once
X86_64
seccomp is enabled via prctl(PR_SET_SECCOMP), it cannot be
disabled and the task is only allowed to execute a few safe syscalls
defined by each seccomp mode.

ARM, ARM64,
If enabled, this allows the libc5 and earlier dynamic linker usblib
USELIB=is not set X86_32, 4.5-4.20, 5.0-5.17
syscall. Should no longer be needed.
X86_64

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
MODIFY_LDT_SYSCALL=is not X86_32,
4.3-4.20, 5.0-5.17 some Wine programs. It is also used by some very old threading
set X86_64
libraries. Enabling this feature adds a small amount of overhead to
context switches and increases the low-level kernel attack surface.
Disabling it removes the modify_ldt(2) system call.

There will be no vsyscall mapping at all. This will eliminate any risk
X86_32, of ASLR bypass due to the vsyscall fixed address mapping.
LEGACY_VSYSCALL_NONE=Y 4.4-4.20, 5.0-5.17
X86_64 Attempts to use the vsyscalls will be reported to dmesg, so that
either old or malicious userspace programs can be identified.

X86_VSYSCALL_EMULATION=is X86_32, 3.19, 4.0-4.20,

If set, this enables emulation of the legacy vsyscall page.
not set X86_64 5.0-5.17

Timesys Corporation, 2022

[Link]
 Security Policy Attacks: These are attacks which attempt to gain elevated (root) privileges within a system, generally through the
use or execution of a misconfigured binary or file. Mitigations for this mostly rely on Linux Security Modules (LSMs) which
extend discretionary access control (DAC) or implement mandatory access control (MAC, Security-Enhanced Linux).

Expected Conditional Architectures Kernel Versions Note

2.5.50-2.5.75,
ARM, ARM64,
2.6.0-2.6.39, 3.0- This allows you to choose different security modules to be
SECURITY=Y X86_32,
3.19, 4.0-4.20, configured into your kernel.
X86_64
5.0-5.17

This selects Yama, which extends DAC support with

additional system-wide security settings beyond regular
ARM, ARM64,
3.4-3.19, 4.0-4.20, Linux discretionary access controls. Currently available is
SECURITY_YAMA=Y X86_32,
5.0-5.17 ptrace scope restriction. Like capabilities, this security
X86_64
module stacks with other LSMs. Further information can be
found in Documentation/admin-guide/LSM/[Link].

If SECURITY_SELINUX_DISABLE must be set, make sure

this is not set. Subsequent patches will add RO hardening
to LSM hooks, however, SELinux still needs to be able to
ARM, ARM64, perform runtime disablement after init to handle
SECURITY_WRITABLE_HOOKS=is not 4.12-4.20, 5.0-
X86_32, architectures where init-time disablement via boot
set 5.17
X86_64 parameters is not feasible. Introduce a new kernel
configuration parameter
CONFIG_SECURITY_WRITABLE_HOOKS, and a helper
macro __lsm_ro_after_init, to handle this case.

ARM, ARM64, 2.6.6-2.6.39, 3.0-

SECURITY_SELINUX_DISABLE=is not
X86_32, 3.19, 4.0-4.20, Do not allow NSA SELinux runtime disable
set
X86_64 5.0-5.17

Enables the lockdown LSM, which enables you to set the

ARM, ARM64, lockdown=integrity or lockdown=confidentiality modes
SECURITY_LOCKDOWN_LSM=Y X86_32, 5.4-5.17 during boot. Integrity attempts to block userspace from
X86_64 modifying the running kernel, while confidentiality also
restricts reading of confidential material.

ARM, ARM64,
SECURITY_LOCKDOWN_LSM_EARLY=Y X86_32, 5.4-5.17 Enable lockdown LSM early in init
X86_64

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
The kernel runs in confidentiality mode by
ARM, ARM64, default. Features that allow the kernel to be
LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=Y X86_32, 5.4-5.17 modified at runtime or that permit userland
X86_64 code to read confidential material held
inside the kernel are disabled.

SafeSetID is an LSM module that gates the

setid family of syscalls to restrict UID/GID
transitions from a given UID/GID to only
ARM, ARM64, those approved by a system-wide whitelist.
SECURITY_SAFESETID=Y X86_32, 5.1-5.17 These restrictions also prohibit the given
X86_64 UIDs/GIDs from obtaining auxiliary
privileges associated with
CAP_SET{U/G}ID, such as allowing a user
to set up user namespace UID mappings.

Any files read through the kernel file reading

interface (kernel modules, firmware, kexec
images, security policy) can be pinned to the
ARM, ARM64, first filesystem used for loading. When
SECURITY_LOADPIN=Y X86_32, 4.7-4.20, 5.0-5.17 enabled, any files that come from other
X86_64 filesystems will be rejected. This is best
used on systems without an initrd that have
a root filesystem backed by a read-only
device such as dm-verity or a CDROM.

If selected, LoadPin will enforce pinning at

ARM, ARM64,
boot. If not selected, it can be enabled at
SECURITY_LOADPIN_ENFORCE=Y X86_32, 4.20, 5.0-5.17
boot with the kernel parameter
X86_64
"[Link]=1".

Timesys Corporation, 2022

[Link]
System Architecture

Many security features are architecture specific because of a specific hardware level reason (differing instruction set, caches, branch
predictors, and more) or merely because they have not been implemented on a specific architecture. Looking at
DEBUG_SET_MODULE_RONX, we find that it was a relatively recent addition for ARM and ARM64 architectures.

Expected Conditional Architectures Kernel Versions Note

X86_32, 2.6.38-2.6.39, 3.0- Helps catch unintended modifications to loadable kernel module's
DEBUG_SET_MODULE_RONX=Y
X86_64 3.19, 4.0-4.10 text and read-only data. It also prevents execution of module data.

3.18-3.19, 4.0-
DEBUG_SET_MODULE_RONX=Y ARM64 ↑
4.10

3.14-3.19, 4.0-
DEBUG_SET_MODULE_RONX=Y ARM ↑
4.10

Looking at the Spectre and Meltdown variants, there are differing options depending on architecture as well:

Expected Conditional Architectures Kernel Versions Note

(Spectre related) Speculation attacks against some high-
performance processors rely on being able to manipulate the
4.16-4.20, 5.0- branch predictor for a victim context by executing aliasing
HARDEN_BRANCH_PREDICTOR=Y ARM, ARM64
5.17 branches in the attacker context. Such attacks can be partially
mitigated against by clearing internal branch predictor state and
limiting the prediction logic in some situations.

X86_32, 4.15-4.20, 5.0-

RETPOLINE=Y Avoid speculative indirect branches in kernel (Spectre Mitigation)
X86_64 5.17

Timesys Corporation, 2022

[Link]
Timesys Kernel Hardening Analysis Tool

This tool is available as part of the meta-vigishield layer, learn more about VigiShield here

This Yocto-based tool can perform some security-minded analysis of your kernel configuration. The tool generates a report that shows
the status of many configuration items which we have assessed as being security related.

The output from the Timesys Kernel Hardening Analysis Tool is formatted as a Comma Separated List (CSV). As an example, here are
the first few lines from a sample report are:

Detected Kernel Version: 5.0.19

Detected Architecture: ARM
Detected configuration at: /mnt/Projects/Yocto/build/tmp/work-shared/qemuarm-uboot/kernel-build-artifacts/.config
Report Generated At: 2022-02-01 12:22:07.088485
Expected Conditional Status Priority Kernel Versions Category Note
4.13-4.20, 5.0- Randomizes layout of sensitive
GCC_PLUGIN_RANDSTRUCT=Y FAILED 3 (High) gcc_plugin
5.17 kernel structures

Generates a separate stack

canary value for each task, so if
SKIPPED
one task's canary value is
GCC_PLUGIN_ARM_SSP_PER_TASK=Y (Version 3 (High) 5.2-5.17 gcc_plugin
leaked it does not cause all
mismatch)
other tasks to become
vulnerable.

This plugin is available to

SKIPPED
identify and zero-initialize stack
GCC_PLUGIN_STRUCTLEAK=Y (Version 3 (High) 5.2-5.17 gcc_plugin
variables that may have passed
mismatch)
through uninitialized

This option 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
4.18-4.20, 5.0-
STACKPROTECTOR=Y PASSED 3 (High) stack_canary just before actually returning.
5.17
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.

Timesys Corporation, 2022

[Link]
 Expected Conditional Status Priority Kernel Versions Category Note
Adds the
CONFIG_STACKPROTECTOR
4.18-4.20, 5.0-
STACKPROTECTOR_STRONG=Y PASSED 3 (High) stack_canary canary logic to additional
5.17
conditions related to variable
assignment.

All page allocator and slab

allocator memory will be zeroed
SKIPPED
when freed, eliminating many
INIT_ON_ALLOC_DEFAULT_ON=Y (Version 3 (High) 5.3-5.17 memory_protection
kinds of "uninitialized heap
mismatch)
memory" flaws, especially heap
content exposures.

More expensive form of

INIT_ON_ALLOC_DEFAULT_ON.
The primary difference is that data
SKIPPED lifetime in memory is reduced, as
INIT_ON_FREE_DEFAULT_ON=Y (Version 3 (High) 5.3-5.17 memory_protection anything freed is wiped
mismatch) immediately, making live forensics
or cold boot memory attacks
unable to recover freed memory
contents.

If this is set, kernel text and

rodata memory will be made
read-only, and non-text memory
4.11-4.20, will be made non-executable. This
STRICT_KERNEL_RWX=Y PASSED 3 (High) memory_protection
5.0-5.17 provides protection against
certain security exploits (e.g.
executing the heap or modifying
text)

(MODULE_SIG_FORCE=Y) OR
FAILED
(MODULES=is not set)

You should not allow for modules

2.5.45-2.5.75, to be loaded unless you have the
2.6.0-2.6.39, 3.0- proper signing and signature
DESCRIPTION: MODULES FAILED 1 (Low) module_security
3.19, 4.0-4.20, checks enabled. Allowing the
5.0-5.17 kernel to load unsigned modules
can be dangerous

DESCRIPTION: 3.7-3.19, 4.0-4.20, Require modules to be validly

FAILED 3 (High) module_security
MODULE_SIG_FORCE 5.0-5.17 signed

In this case, GCC_PLUGIN_RANDSTRUCT was not enabled in the kernel configuration file, so the return status is, "FAILED."

GCC_PLUGIN_ARM_SSP_PER_TASK, GCC_PLUGIN_STRUCTLEAK, INIT_ON_ALLOC_DEFAULT_ON,

STRICT_KERNEL_RWX, and INIT_ON_FREE_DEFAULT_ON are all options which were available after the 5.0.19 kernel version,
so those have been skipped with a, "SKIPPED (Version mismatch)" message.

The rest of the options were set appropriately and passed (STACKPROTECTOR and STACKPROTECTOR_STRONG).

Modules are also enabled without any forced signature checking, so the OR conditional [(MODULE_SIG_FORCE=Y) OR
(MODULES=is not set)] for that has also failed.

This is the entire list of conditions which the Timesys Kernel Hardening Analysis Tool presently considers:

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
ARM, ARM64, 2.6.12-2.6.39, 3.0-
Enabling this will cause processes to terminate on BUG()
BUG=Y X86_32, 3.19, 4.0-4.20,
conditions
X86_64 5.0-5.17

ARM, ARM64, 2.6.9-2.6.39, 3.0-

Make sure this is not enabled, as it could provide an attacker
DEBUG_BUGVERBOSE=is not set X86_32, 3.19, 4.0-4.20,
sensitive kernel backtrace information on BUG() conditions
X86_64 5.0-5.17

Not necessary (redundant) past 5.3 if you enable

ARM, ARM64, 2.6.22-2.6.39, 3.0- INIT_ON_ALLOC_DEFAULT_ON! With this enabled, you can
SLUB_DEBUG=Y X86_32, 3.19, 4.0-4.20, enable slab poisoning from your boot cmdline with slub_debug=P.
X86_64 5.0-5.17 This will ensure object and padding areas in the slab memory are
less vulnerable to leakage.

Boot with debugging on by default. SLUB boots by default with

the runtime debug capabilities switched off. Enabling this is
ARM, ARM64, 2.6.23-2.6.39, 3.0- equivalent to specifying the "slub_debug" parameter on boot.
SLUB_DEBUG_ON=Y X86_32, 3.19, 4.0-4.20, There is no support for more fine grained debug control like
X86_64 5.0-5.17 possible with slub_debug=xxx. SLUB debugging may be switched
off in a kernel built with CONFIG_SLUB_DEBUG_ON by
specifying "slub_debug=-".

Fill the pages with poison patterns after free_pages() and verify
ARM, ARM64,
the patterns before alloc_pages. The filling of the memory helps
PAGE_POISONING=Y X86_32, 4.6-4.20, 5.0-5.17
reduce the risk of information leaks from freed data. This must be
X86_64
enabled from the boot cmdline with page_poison=1

ARM, ARM64, Skip the sanity checking on alloc, only fill the pages with poison
PAGE_POISONING_NO_SANITY=is
X86_32, 4.6-4.20, 5.0-5.10 on free. This reduces some of the overhead of the poisoning
not set
X86_64 feature.

Instead of using the existing poison value, fill the pages with
ARM, ARM64, zeros. This makes it harder to detect when errors are occurring
4.19-4.20, 5.0-
PAGE_POISONING_ZERO=Y X86_32, due to sanitization but the zeroing at free means that it is no
5.10
X86_64 longer necessary to write zeros when GFP_ZERO is used on
allocation.

If this is set, kernel text and rodata memory will be made read-
ARM, ARM64,
4.11-4.20, 5.0- only, and non-text memory will be made non-executable. This
STRICT_KERNEL_RWX=Y X86_32,
5.17 provides protection against certain security exploits (e.g.
X86_64
executing the heap or modifying text)

ARM, ARM64,
2.6.16-2.6.39, 3.0-
DEBUG_RODATA=Y X86_32, Same as CONFIG_STRICT_KERNEL_RWX prior to 4.11
3.19, 4.0-4.10
X86_64

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
Initializes everything on the stack with a 0xAA pattern. This is
ARM, ARM64,
intended to eliminate all classes of uninitialized stack variable
INIT_STACK_ALL=Y X86_32, 5.2-5.8
exploits and information exposures, even variables that were
X86_64
warned to have been left uninitialized.

Initializes everything on the stack with a 0xAA pattern. This is

ARM, ARM64,
intended to eliminate all classes of uninitialized stack variable
INIT_STACK_ALL_PATTERN=Y X86_32, 5.9-5.17
exploits and information exposures, even variables that were
X86_64
warned to have been left uninitialized.

Initializes everything on the stack with a zero value. This is

ARM, ARM64,
intended to eliminate all classes of uninitialized stack variable
INIT_STACK_ALL_ZERO=Y X86_32, 5.9-5.17
exploits and information exposures, even variables that were
X86_64
warned to have been left uninitialized. (Strongest, safest)

More expensive form of INIT_ON_ALLOC_DEFAULT_ON. The

ARM, ARM64,
primary difference is that data lifetime in memory is reduced, as
INIT_ON_FREE_DEFAULT_ON=Y X86_32, 5.3-5.17
anything freed is wiped immediately, making live forensics or cold
X86_64
boot memory attacks unable to recover freed memory contents.

ARM, ARM64, All page allocator and slab allocator memory will be zeroed when
INIT_ON_ALLOC_DEFAULT_ON=Y X86_32, 5.3-5.17 freed, eliminating many kinds of "uninitialized heap memory" flaws,
X86_64 especially heap content exposures.

ARM, ARM64,
Perform full reference count validation, protecting against various
REFCOUNT_FULL=Y X86_32, 4.13-4.20, 5.0-5.4
user-after-free security flaw conditions, at the expense of speed
X86_64

ARM, ARM64,
3.1-3.19, 4.0-4.20,
IOMMU_SUPPORT=Y X86_32, For mitigating DMA attacks
5.0-5.17
X86_64

ARM, ARM64,
ARCH_HAS_ELF_RANDOMIZE=Y X86_32, 4.1-4.20, 5.0-5.17 Randomized locations for stack, mmap, brk, and ET_DYN
X86_64

ARM, ARM64,
DEBUG_ALIGN_RODATA=Y X86_32, 4.6-4.20, 5.0-5.17 If this is set, rodata will be made explicitly non-executable.
X86_64

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
2.6.24-2.6.39, 3.0-
Split memory between user/kernel (3G/1G) for maximal userspace
VMSPLIT_3G=Y ARM, X86_32 3.19, 4.0-4.20,
memory
5.0-5.17

This value can be used to select the number of bits to use to determine
X86_64,
ARCH_MMAP_RND_BITS=32 4.5-4.20, 5.0-5.17 the random offset to the base address of vma regions resulting from
ARM64
mmap allocations.

This value can be used to select the number of bits to use to determine
ARCH_MMAP_RND_BITS=16 X86_32, ARM 4.5-4.20, 5.0-5.17 the random offset to the base address of vma regions resulting from
mmap allocations.

X86_32,
MICROCODE=Y 4.4-4.20, 5.0-5.17 For Mitigating CPU bugs
X86_64

X86_32, 4.15-4.20, 5.0-

RETPOLINE=Y Avoid speculative indirect branches in kernel (Spectre Mitigation)
X86_64 5.17

X86_32, 3.7-3.19, 4.0-4.20,

X86_SMAP=Y Supervisor Mode Access Prevention
X86_64 5.0-5.17

If enabled, a general protection fault is issued if the SGDT, SLDT, SIDT,

X86_32,
X86_UMIP=Y 5.5-5.17 SMSW or STR instructions are executed in user mode. These
X86_64
instructions unnecessarily expose information about the hardware state.

X86_32,
X86_INTEL_UMIP=Y 4.15-4.20, 5.0-5.4 Same as X86_UMIP, prior to 5.5
X86_64

ARM, ARM64,
4.15-4.20, 5.0- This feature reduces the number of hardware side channels by ensuring
PAGE_TABLE_ISOLATION=Y X86_32,
5.17 that the majority of kernel addresses are not mapped into userspace.
X86_64

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
Randomizes the base virtual address of kernel memory
sections (physical memory mapping, vmalloc & vmemmap).
RANDOMIZE_MEMORY=Y X86_64 4.8-4.20, 5.0-5.17
This security feature makes exploits relying on predictable
memory locations less reliable.

Intel IOMMU support: Isolates the DMA memory of different

3.2-3.19, 4.0-4.20,
INTEL_IOMMU=Y X86_64 devices and protect the system from misbehaving device
5.0-5.17
drivers or hardware

AMD IOMMU support: Isolates the DMA memory of different

3.1-3.19, 4.0-4.20,
AMD_IOMMU=Y X86_64 devices and protect the system from misbehaving device
5.0-5.17
drivers or hardware

Privileged Access Never (PAN; part of the ARMv8.1

Extensions) prevents the kernel or hypervisor from
ARM64_PAN=Y ARM64 4.3-4.20, 5.0-5.17 accessing user-space (EL0) memory directly. Choosing this
option will cause any unprotected (not using copy_to_user et
al) memory access to fail with a permission fault.

Speculation attacks against some high-performance

processors can be used to bypass MMU permission checks
4.16-4.20, 5.0- and leak kernel data to userspace. This can be defended
UNMAP_KERNEL_AT_EL0=Y ARM64
5.17 against by unmapping the kernel when running in
userspace, mapping it back in on exception entry via a
trampoline page in the vector table.

Speculation attacks against some high-performance

processors can be used to leak privileged information such
as the vector base register, resulting in a potential defeat of
the EL2 layout randomization. This config option will map the
HARDEN_EL2_VECTORS=Y ARM64 4.17-4.20, 5.0-5.8
vectors to a fixed location, independent of the EL2 code
mapping, so that revealing VBAR_EL2 to an attacker does
not give away any extra information. This only gets enabled
on affected CPUs.

Apply read-only attributes of VM areas to the linear alias of

the backing pages as well. This prevents code or read-only
RODATA_FULL_DEFAULT_ENABLED=Y ARM64 5.0-5.17
data from being modified (inadvertently or intentionally) via
another mapping of the same memory page.

Pointer authentication (part of the ARMv8.3 Extensions)

provides instructions for signing and authenticating pointers
against secret keys, which can be used to mitigate Return
Oriented Programming (ROP) and other attacks. This option
ARM64_PTR_AUTH=Y ARM64 5.0-5.17
enables these instructions at EL0 (i.e. for userspace).
Choosing this option will cause the kernel to initialise secret
keys for each process at exec() time, with these keys being
context-switched along with the process.

If the compiler supports the -mbranch-protection or -msign-

return-address flag (e.g. GCC 7 or later), then this option will
cause the kernel itself to be compiled with return address
ARM64_PTR_AUTH_KERNEL=Y ARM64 5.14-5.17
protection. In this case, and if the target hardware is known
to support pointer authentication, then STACKPROTECTOR
can be disabled with minimal loss of protection.

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
Enable this if you want the use virtually-mapped kernel stacks
X86_64,
VMAP_STACK=Y 4.9-4.20, 5.0-5.17 with guard pages. This causes kernel stack overflows to be
ARM64
caught immediately.

In support of Kernel Address Space Layout Randomization

(KASLR), this randomizes the physical address at which the
ARM64,
kernel image is decompressed and the virtual address where the
RANDOMIZE_BASE=Y X86_32, 4.7-4.20, 5.0-5.17
kernel image is mapped, as a security feature that deters exploit
X86_64
attempts relying on knowledge of the location of kernel code
internals.

ARM64,
Protects thread_info structure address by moving it out of the
THREAD_INFO_IN_TASK=Y X86_32, 4.9-4.20, 5.0-5.17
stack and info task_struct.
X86_64

Increase kernel security by ensuring that normal kernel accesses

are unable to access userspace addresses. This can help
CPU_SW_DOMAIN_PAN=Y ARM 4.3-4.20, 5.0-5.17 prevent use-after-free bugs becoming an exploitable privilege
escalation by ensuring that magic values (such as
LIST_POISON) will always fault when dereferenced.

(Spectre related) Speculation attacks against some high-

performance processors rely on being able to manipulate the
4.16-4.20, 5.0- branch predictor for a victim context by executing aliasing
HARDEN_BRANCH_PREDICTOR=Y ARM, ARM64
5.17 branches in the attacker context. Such attacks can be partially
mitigated against by clearing internal branch predictor state and
limiting the prediction logic in some situations.

ARM, ARM64,
Generate a warning if any W+X mappings are found at boot.
DEBUG_WX=Y X86_32, 4.4-4.20, 5.0-5.17
Effectively reports any dangerous memory permissions.
X86_64

Harden slab freelist metadata: Many kernel heap attacks try to

target slab cache metadata and other infrastructure. This options
ARM, ARM64,
4.14-4.20, 5.0- makes minor performance sacrifices to harden the kernel slab
SLAB_FREELIST_HARDENED=Y X86_32,
5.17 allocator against common freelist exploit methods. Some slab
X86_64
implementations have more sanity-checking than others. This
option is most effective with CONFIG_SLUB.

ARM, ARM64, Randomizes the freelist order used on creating new pages. This
SLAB_FREELIST_RANDOM=Y X86_32, 4.7-4.20, 5.0-5.17 security feature reduces the predictability of the kernel slab
X86_64 allocator against heap overflows.

ARM, ARM64,
Reduces the predictability of page allocations to compliment
SHUFFLE_PAGE_ALLOCATOR=Y X86_32, 5.2-5.17
SLAB_FREELIST_RANDOM
X86_64

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
ARM, ARM64,
4.13-4.20, 5.0-
FORTIFY_SOURCE=Y X86_32, Harden common str/mem functions against buffer overflows
5.17
X86_64

ARM, ARM64, 2.6.19-2.6.39, 3.0- Additional validation check on commonly targeted structure.
DEBUG_LIST=Y X86_32, 3.19, 4.0-4.20, Enable this to turn on extended checks in the linked-list walking
X86_64 5.0-5.17 routines.

ARM, ARM64, 2.6.24-2.6.39, 3.0-

Additional validation check on commonly targeted structure.
DEBUG_SG=Y X86_32, 3.19, 4.0-4.20,
Enable this to turn on checks on scatter-gather tables.
X86_64 5.0-5.17

Additional validation check on commonly targeted structure.

Enable this to turn on some debug checking for credential
ARM, ARM64, 2.6.32-2.6.39, 3.0- management. The additional code keeps track of the number of
DEBUG_CREDENTIALS=Y X86_32, 3.19, 4.0-4.20, pointers from task_structs to any given cred struct, and checks to
X86_64 5.0-5.17 see that this number never exceeds the usage count of the cred
struct. Furthermore, if SELinux is enabled, this also checks that
the security pointer in the cred struct is never seen to be invalid.

Additional validation check on commonly targeted structure.

Enable this to turn on sanity checking for notifier call chains. This
ARM, ARM64, 2.6.29-2.6.39, 3.0-
is most useful for kernel developers to make sure that modules
DEBUG_NOTIFIERS=Y X86_32, 3.19, 4.0-4.20,
properly unregister themselves from notifier chains. This is a
X86_64 5.0-5.17
relatively cheap check but if you care about maximum
performance, say N.

Additional validation check on commonly targeted structure. Select

ARM, ARM64,
4.10-4.20, 5.0- this option if the kernel should BUG when it encounters data
BUG_ON_DATA_CORRUPTION=Y X86_32,
5.17 corruption in kernel memory structures when they get checked for
X86_64
validity.

ARM, ARM64,
3.18-3.19, 4.0- Additional validation check on commonly targeted structure.
SCHED_STACK_END_CHECK=Y X86_32,
4.20, 5.0-5.17 Detect stack corruption on calls to schedule()
X86_64

All page allocator and slab allocator memory will be zeroed when
ARM, ARM64, allocated, eliminating many kinds of "uninitialized heap memory"
INIT_ON_ALLOC_DEFAULT_ON=Y X86_32, 5.3-5.17 flaws, especially heap content exposures. The performance
X86_64 impact varies by workload, but most cases see <1% impact. Some
synthetic workloads have measured as high as 7%.

ARM, ARM64, 2.6.35-2.6.39, 3.0-

SYN_COOKIES=Y X86_32, 3.19, 4.0-4.20, Mitigation against TCP/IP SYN flooding
X86_64 5.0-5.17

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
This is the portion of low virtual memory which should be
2.6.31-2.6.39, 3.0-
X86_32, protected from userspace allocation. Keeping a user from
DEFAULT_MMAP_MIN_ADDR=65536 3.19, 4.0-4.20,
X86_64 writing to low pages can help reduce the impact of kernel NULL
5.0-5.17
pointer bugs.

2.6.24-2.6.39, 3.0-
Select this if you have a 32-bit processor and more than 4
HIGHMEM64G=Y X86_32 3.19, 4.0-4.20,
gigabytes of physical RAM.
5.0-5.17

PAE is required for NX support, and furthermore enables larger

2.6.24-2.6.39, 3.0-
swapspace support for non-overcommit purposes. It has the
X86_PAE=Y X86_32 3.19, 4.0-4.20,
cost of more pagetable lookup overhead, and also consumes
5.0-5.17
more pagetable space per process.

Enabling this option prevents the kernel from accessing user-

4.10-4.20, 5.0- space memory directly by pointing TTBR0_EL1 to a reserved
ARM64_SW_TTBR0_PAN=Y ARM64
5.17 zeroed area and reserved ASID. The user access routines
restore the valid TTBR0_EL1 temporarily.

This is the portion of low virtual memory which should be

2.6.31-2.6.39, 3.0-
protected from userspace allocation. Keeping a user from
DEFAULT_MMAP_MIN_ADDR=32768 ARM, ARM64 3.19, 4.0-4.20,
writing to low pages can help reduce the impact of kernel NULL
5.0-5.17
pointer bugs.

This enforces restrictions on unprivileged users reading the

ARM, ARM64, 2.6.37-2.6.39, 3.0-
kernel syslog via dmesg(8). If this option is not selected, no
SECURITY_DMESG_RESTRICT=Y X86_32, 3.19, 4.0-4.20,
restrictions will be enforced unless the dmesg_restrict sysctl is
X86_64 5.0-5.17
explicitly set to (1).

ARM, ARM64, 2.6.28-2.6.39, 3.0-

Enable some costly sanity checks in virtual to page code. This
DEBUG_VIRTUAL=Y X86_32, 3.19, 4.0-4.20,
can catch mistakes with virt_to_page() and friends.
X86_64 5.0-5.17

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
ARM, ARM64,
4.11-4.20, 5.0- itself, or as a kernel configuration option. However, some of
STATIC_USERMODEHELPER=Y X86_32,
5.17 these are dynamically created at runtime, or can be modified
X86_64
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.

Disable the busmaster bit in the control register on all PCI

ARM, ARM64, bridges while calling ExitBootServices() and passing control to
EFI_DISABLE_PCI_DMA=Y X86_32, 5.6-5.17 the runtime kernel. System firmware may configure the IOMMU
X86_64 to prevent malicious PCI devices from being able to attack the
OS via DMA.

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
ARM, ARM64,
EFI_CUSTOM_SSDT_OVERLAYS=is Allow loading of an ACPI SSDT overlay from an EFI variable
X86_32, 5.8-5.17
not set specified by a kernel command line option.
X86_64

For reduced kernel memory fragmentation, slab caches can be

merged when they share the same size and other
characteristics. This carries a risk of kernel heap overflows
ARM, ARM64, being able to overwrite objects from merged caches (and more
4.13-4.20, 5.0-
SLAB_MERGE_DEFAULT=is not set X86_32, easily control cache layout), which makes such heap attacks
5.17
X86_64 easier to exploit by attackers. By keeping caches unmerged,
these kinds of exploits can usually only damage objects in the
same cache. To disable merging at runtime, "slab_nomerge"
can be passed on the kernel command line.

ARM, ARM64,
RANDOM_TRUST_BOOTLOADER=is
X86_32, 5.4-5.17 Do not trust entropy generated by the bootloader
not set
X86_64

ARM, ARM64,
4.19-4.20, 5.0-
RANDOM_TRUST_CPU=is not set X86_32, Do not trust CPU manufacturer for initializating CRNG
5.17
X86_64

ARM64,
If this is set, STACKLEAK metrics for every task are available in
STACKLEAK_METRICS=is not set X86_32, 5.2-5.17
the /proc file system.
X86_64

ARM64,
STACKLEAK_RUNTIME_DISABLE=is
X86_32, 5.2-5.17 If set, allows runtime disabling of kernel stack erasing
not set
X86_64

Shared Virtual Memory (SVM) provides a facility for devices to

X86_32,
INTEL_IOMMU_SVM=Y 4.4-4.20, 5.0-5.17 access DMA resources through process address space by
X86_64
means of a Process Address Space ID (PASID).

Selecting this option will enable a DMAR device at boot time if

X86_32, 3.2-3.19, 4.0-4.20,
INTEL_IOMMU_DEFAULT_ON=Y one is found. If this option is not selected, DMAR support can
X86_64 5.0-5.17
be enabled by passing intel_iommu=on to the kernel.

DMA remapping (DMAR) devices support enables independent

address translations for Direct Memory Access (DMA) from
3.2-3.19, 4.0-4.20,
INTEL_IOMMU=Y X86_32 devices. These DMA remapping devices are reported via ACPI
5.0-5.17
tables and include PCI device scope covered by these DMA
remapping devices.

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
This option enables support for the AMD IOMMUv2
3.9-3.19, 4.0-4.20, features of the IOMMU hardware. Select this option if
AMD_IOMMU_V2=Y X86_64
5.0-5.17 you want to use devices that support the PCI PRI and
PASID interface.

Request that the firmware clear the contents of RAM

ARM, ARM64, after a reboot using the TCG Platform Reset Attack
4.14-4.20, 5.0-
RESET_ATTACK_MITIGATION=Y X86_32, Mitigation specification. This protects against an
5.17
X86_64 attacker forcibly rebooting the system while it still
contains secrets in RAM.

Build the kernel with Branch Target Identification

annotations and enable enforcement of this for kernel
ARM64_BTI_KERNEL=Y ARM64 5.8-5.17 code. When this option is enabled and the system
supports BTI all kernel code including modular code
must have BTI enabled.

This option enables the support for the Memory

ARM64_MTE=Y ARM64 5.10-5.17
Tagging Extension at EL0 (i.e. for userspace).

Enhanced Privileged Access Never (EPAN) allows

ARM64_EPAN=Y ARM64 5.13-5.17 Privileged Access Never to be used with Execute-only
mappings.

KASAN_HW_TAGS=Y ARM64 5.11-5.17 Enables hardware tag-based KASAN mode.

The kernel stack offset can be randomized (after

pt_regs) by roughly 5 bits of entropy, frustrating
ARM, ARM64, memory corruption attacks that depend on stack
RANDOMIZE_KSTACK_OFFSET_DEFAULT=Y X86_32, 5.13-5.17 address determinism or cross-syscall address
X86_64 exposures. This feature is controlled by kernel boot
param "randomize_kstack_offset=on/off", and this
config chooses the default boot state.

ARM, ARM64, This option enables detection of directly indexed out of

UBSAN_BOUNDS=Y X86_32, 5.7-5.17 bounds array accesses, where the array size is known
X86_64 at compile time.

This option activates instrumentation for the entire

kernel. If you don't enable this option, you have to
ARM, ARM64,
explicitly specify UBSAN_SANITIZE := y for the
UBSAN_SANITIZE_ALL=Y X86_32, 5.7-5.17
files/directories you want to check for UB. Enabling
X86_64
this option will get kernel image size increased
significantly.

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
Building kernels with Sanitizer features enabled
tends to grow the kernel size by around 5%, due to
adding all the debugging text on failure paths. To
avoid this, Sanitizer instrumentation can just issue
ARM, ARM64, a trap. This reduces the kernel size overhead but
UBSAN_TRAP=Y X86_32, 5.7-5.17 turns all warnings (including potentially harmless
X86_64 conditions) into full exceptions that abort the
running kernel code (regardless of context, locks
held, etc), which may destabilize the system. For
some system builders this is an acceptable trade-
off.

This option enables Clang's Shadow Call Stack,

ARM, ARM64, which uses a shadow stack to protect function
SHADOW_CALL_STACK=Y X86_32, 5.8-5.17 return addresses from being overwritten by an
X86_64 attacker. More information can be found in Clang's
documentation:

This option enables Clang's forward-edge Control

ARM, ARM64, Flow Integrity (CFI) checking, where the compiler
CFI_CLANG=Y X86_32, 5.13-5.17 injects a runtime check to each indirect function
X86_64 call to ensure the target is a valid function with the
correct static type.

This option checks for obviously wrong memory

ARM, ARM64,
regions when copying memory to/from the kernel
HARDENED_USERCOPY=Y X86_32, 4.8-4.20, 5.0-5.17
(via copy_to_user() and copy_from_user()
X86_64
functions).

This is a temporary option that allows missing

usercopy whitelists to be discovered via a WARN()
ARM, ARM64,
4.16-4.20, 5.0- to the kernel log, instead of rejecting the copy,
HARDENED_USERCOPY_FALLBACK=is not set X86_32,
5.15 falling back to non-whitelisted hardened usercopy
X86_64
that checks the slab allocation size instead of the
whitelist size.

When a multi-page allocation is done without

__GFP_COMP, hardened usercopy will reject
ARM, ARM64,
attempts to copy it. There are, however, several
HARDENED_USERCOPY_PAGESPAN=is not set X86_32, 4.8-4.20, 5.0-5.17
cases of this in the kernel that have not all been
X86_64
removed. This config is intended to be used only
while trying to find such users.

ARM, ARM64, The heap allocator implements

HAVE_HARDENED_USERCOPY_ALLOCATOR=Y X86_32, 4.8-4.20, 5.0-5.17 __check_heap_object() for validating memory
X86_64 ranges against heap object sizes.

Enables support for the io_uring interface, enabling

ARM, ARM64,
applications to submit and complete IO through
IO_URING=is not set X86_32, 5.1-5.17
submission and completion rings that are shared
X86_64
between the kernel and application.

ARM, ARM64,
Enables compiler plugins which can be used for
GCC_PLUGINS=Y X86_32, 4.8-4.20, 5.0-5.17
security hardening
X86_64

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
ARM, ARM64,
Generates additional entropy within the system at
GCC_PLUGIN_LATENT_ENTROPY=Y X86_32, 4.9-4.20, 5.0-5.17
the cost of boot time, forking, and irq processing.
X86_64

ARM, ARM64,
4.13-4.20, 5.0-
GCC_PLUGIN_RANDSTRUCT=Y X86_32, Randomizes layout of sensitive kernel structures
5.17
X86_64

Restricts structure randomization to cacheline-

ARM, ARM64, sized groups of elements and will not further
GCC_PLUGIN_RANDSTRUCT_PERFORMANCE=is 4.13-4.20, 5.0-
X86_32, randomize bitfields in structures. This reduces
not set 5.17
X86_64 the performance hit of CONFIG_RANDSTRUCT
at the cost of weakened randomization.

ARM, ARM64, This plugin is available to identify and zero-

GCC_PLUGIN_STRUCTLEAK=Y X86_32, 5.2-5.17 initialize stack variables that may have passed
X86_64 through uninitialized

ARM, ARM64,
GCC_PLUGIN_STRUCTLEAK_USER=Y X86_32, 5.2-5.17 Zero-init structs marked for userspace (weak)
X86_64

ARM, ARM64,
GCC_PLUGIN_STRUCTLEAK_BYREF=Y X86_32, 5.2-5.17 Zero-init structs passed by reference (strong)
X86_64

ARM, ARM64,
Zero-init anything passed by reference (very
GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=Y X86_32, 5.2-5.17
strong)
X86_64

This blocks most uninitialized stack variable

attacks, with the performance impact being
ARM64,
driven by the depth of the stack usage, rather
GCC_PLUGIN_STACKLEAK=Y X86_32, 5.2-5.17
than the function calling complexity. The
X86_64
performance impact on a single CPU system
kernel compilation sees a 1% slowdown.

Generates a separate stack canary value for

each task, so if one task's canary value is leaked
GCC_PLUGIN_ARM_SSP_PER_TASK=Y ARM 5.2-5.17
it does not cause all other tasks to become
vulnerable.

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
This option turns on the "stack-protector" GCC feature. This
feature puts, at the beginning of functions, a canary value on
ARM, ARM64, the stack just before the return address, and validates the value
4.18-4.20, 5.0-
STACKPROTECTOR=Y X86_32, just before actually returning. Stack based buffer overflows
5.17
X86_64 (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.

ARM, ARM64,
4.18-4.20, 5.0- Adds the CONFIG_STACKPROTECTOR canary logic to
STACKPROTECTOR_STRONG=Y X86_32,
5.17 additional conditions related to variable assignment.
X86_64

ARM, ARM64,
3.14-3.19, 4.0-
CC_STACKPROTECTOR=Y X86_32, Same as CONFIG_STACKPROTECTOR (prior to 4.18)
4.15
X86_64

ARM, ARM64,
3.14-3.19, 4.0- Same as CONFIG_STACKPROTECTOR_STRONG (prior to
CC_STACKPROTECTOR_STRONG=Y X86_32,
4.17 4.18)
X86_64

STACKPROTECTOR_PER_TASK=Y ARM, ARM64 5.0-5.17 Use a different stack canary value for each task

ARM, ARM64, You should not allow for modules to be loaded unless you have
MODULES=is not set X86_32, the proper signing and signature checks enabled. Allowing the
X86_64 kernel to load unsigned modules can be dangerous

ARM, ARM64, Module text and rodata memory will be made read-only, and
4.11-4.20, 5.0-
STRICT_MODULE_RWX=Y X86_32, non-text memory will be made non-executable. This provides
5.17
X86_64 protection against certain security exploits (e.g. writing to text)

ARM, ARM64,
3.7-3.19, 4.0-4.20,
MODULE_SIG=Y X86_32, Enable module signature verification
5.0-5.17
X86_64

ARM, ARM64,
3.9-3.19, 4.0-4.20, Automatically sign all modules during modules_install (so we
MODULE_SIG_ALL=Y X86_32,
5.0-5.17 don't have to do this manually)
X86_64

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
ARM, ARM64,
3.7-3.19, 4.0-4.20,
MODULE_SIG_SHA512=Y X86_32, Sign modules with SHA-512 algorithm
5.0-5.17
X86_64

ARM, ARM64,
3.7-3.19, 4.0-4.20,
MODULE_SIG_FORCE=Y X86_32, Require modules to be validly signed
5.0-5.17
X86_64

ARM, ARM64, Helps catch unintended modifications to loadable kernel

Varies depending
DEBUG_SET_MODULE_RONX=Y X86_32, module's text and read-only data. It also prevents execution
on architecture
X86_64 of module data.

2.5.50-2.5.75,
ARM, ARM64,
2.6.0-2.6.39, 3.0- This allows you to choose different security modules to be
SECURITY=Y X86_32,
3.19, 4.0-4.20, configured into your kernel.
X86_64
5.0-5.17

This selects Yama, which extends DAC support with

additional system-wide security settings beyond regular
ARM, ARM64,
3.4-3.19, 4.0-4.20, Linux discretionary access controls. Currently available is
SECURITY_YAMA=Y X86_32,
5.0-5.17 ptrace scope restriction. Like capabilities, this security
X86_64
module stacks with other LSMs. Further information can be
found in Documentation/admin-guide/LSM/[Link].

If SECURITY_SELINUX_DISABLE must be set, make sure

this is not set. Subsequent patches will add RO hardening
to LSM hooks, however, SELinux still needs to be able to
ARM, ARM64, perform runtime disablement after init to handle
SECURITY_WRITABLE_HOOKS=is not 4.12-4.20, 5.0-
X86_32, architectures where init-time disablement via boot
set 5.17
X86_64 parameters is not feasible. Introduce a new kernel
configuration parameter
CONFIG_SECURITY_WRITABLE_HOOKS, and a helper
macro __lsm_ro_after_init, to handle this case.

ARM, ARM64, 2.6.6-2.6.39, 3.0-

SECURITY_SELINUX_DISABLE=is not
X86_32, 3.19, 4.0-4.20, Do not allow NSA SELinux runtime disable
set
X86_64 5.0-5.17

Enables the lockdown LSM, which enables you to set the

ARM, ARM64, lockdown=integrity or lockdown=confidentiality modes
SECURITY_LOCKDOWN_LSM=Y X86_32, 5.4-5.17 during boot. Integrity attempts to block userspace from
X86_64 modifying the running kernel, while confidentiality also
restricts reading of confidential material.

ARM, ARM64,
SECURITY_LOCKDOWN_LSM_EARLY=Y X86_32, 5.4-5.17 Enable lockdown LSM early in init
X86_64

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
The kernel runs in confidentiality mode by
ARM, ARM64, default. Features that allow the kernel to be
LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=Y X86_32, 5.4-5.17 modified at runtime or that permit userland
X86_64 code to read confidential material held
inside the kernel are disabled.

SafeSetID is an LSM module that gates the

setid family of syscalls to restrict UID/GID
transitions from a given UID/GID to only
ARM, ARM64, those approved by a system-wide whitelist.
SECURITY_SAFESETID=Y X86_32, 5.1-5.17 These restrictions also prohibit the given
X86_64 UIDs/GIDs from obtaining auxiliary
privileges associated with
CAP_SET{U/G}ID, such as allowing a user
to set up user namespace UID mappings.

Any files read through the kernel file reading

interface (kernel modules, firmware, kexec
images, security policy) can be pinned to the
ARM, ARM64, first filesystem used for loading. When
SECURITY_LOADPIN=Y X86_32, 4.7-4.20, 5.0-5.17 enabled, any files that come from other
X86_64 filesystems will be rejected. This is best
used on systems without an initrd that have
a root filesystem backed by a read-only
device such as dm-verity or a CDROM.

If selected, LoadPin will enforce pinning at

ARM, ARM64,
boot. If not selected, it can be enabled at
SECURITY_LOADPIN_ENFORCE=Y X86_32, 4.20, 5.0-5.17
boot with the kernel parameter
X86_64
"[Link]=1".

This kernel feature is useful for number

crunching applications that may need to
compute untrusted bytecode during their
execution. By using pipes or other
transports made available to the process as
ARM, ARM64, 2.6.24-2.6.39, 3.0- file descriptors supporting the read/write
SECCOMP=Y X86_32, 3.19, 4.0-4.20, syscalls, it's possible to isolate those
X86_64 5.0-5.17 applications in their own address space
using seccomp. Once seccomp is enabled
via prctl(PR_SET_SECCOMP), it cannot be
disabled and the task is only allowed to
execute a few safe syscalls defined by each
seccomp mode.

Enable tasks to build secure computing

ARM, ARM64,
3.5-3.19, 4.0-4.20, environments defined in terms of Berkeley
SECCOMP_FILTER=Y X86_32,
5.0-5.17 Packet Filter programs which implement
X86_64
task-defined system call filtering polices.

ARM, ARM64,
Do not allow access to physical memory via
DEVMEM=is not set X86_32, 4.0-4.20, 5.0-5.17
/dev/mem
X86_64

If this option is disabled, you allow

ARM, ARM64, userspace (root) access to all io-memory
IO_STRICT_DEVMEM=Y X86_32, 4.5-4.20, 5.0-5.17 regardless of whether a driver is actively
X86_64 using that range. Accidental access to this is
obviously disastrous.

If this option is disabled, you allow

ARM, ARM64, 2.6.27-2.6.39, 3.0- userspace (root) access to all of memory,
STRICT_DEVMEM=Y X86_32, 3.19, 4.0-4.20, including kernel and userspace memory.
X86_64 5.0-5.17 Accidental access to this is obviously
disastrous.

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
This option is security sensitive, because it allows arbitrary kernel
ARM, ARM64, memory to be written to by root (uid=0) users, allowing them to bypass
ACPI_CUSTOM_METHOD=is 3.0-3.19, 4.0-4.20,
X86_32, certain security measures (e.g. if root is not allowed to load additional
not set 5.0-5.17
X86_64 kernel modules after boot, this feature may be used to override that
restriction).

ARM, ARM64, 2.6.25-2.6.39, 3.0-

COMPAT_BRK=is not set X86_32, 3.19, 4.0-4.20, Do not disable heap randomization
X86_64 5.0-5.17

ARM, ARM64, 2.6.26-2.6.39, 3.0-

DEVKMEM=is not set X86_32, 3.19, 4.0-4.20, Do not expose /dev/kmem device
X86_64 5.0-5.12

X86_32, 2.6.24-2.6.39, 3.0-

COMPAT_VDSO=is not set X86_64, 3.15-3.19, 4.0- Legacy VSDO mapping, not needed with newer GLIBC versions
ARM64 4.20, 5.0-5.17

2.5.73-2.5.75,
ARM, ARM64,
2.6.0-2.6.39, 3.0-
BINFMT_MISC=is not set X86_32, Do not allow wrapper-driven binary formats into the kernel
3.19, 4.0-4.20,
X86_64
5.0-5.17

ARM, ARM64, 2.6.14-2.6.39, 3.0-

Do not allow INET socket monitoring interface. Assists heap memory
INET_DIAG=is not set X86_32, 3.19, 4.0-4.20,
attacks
X86_64 5.0-5.17

ARM, ARM64, 2.6.16-2.6.39, 3.0-

KEXEC=is not set X86_32, 3.19, 4.0-4.20, Do not allow system to boot another Linux kernel
X86_64 5.0-5.17

ARM, ARM64,
3.17-3.19, 4.0-
KEXEC_FILE=is not set X86_32, Do not allow system to boot another Linux kernel
4.20, 5.0-5.17
X86_64

ARM, ARM64, 2.6.27-2.6.39, 3.0-

Do not provide a virtual ELF core file of the live kernel (which could be
PROC_KCORE=is not set X86_32, 3.19, 4.0-4.20,
read by GDB and other tools to obtain privileged information)
X86_64 5.0-5.17

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
Disable legacy psuedo terminal (PTY) support. Linux has traditionally
ARM, ARM64,
2.6.39, 3.0-3.19, used the BSD-like names /dev/ptyxx for masters and /dev/ttyxx for
LEGACY_PTYS=is not set X86_32,
4.0-4.20, 5.0-5.17 slaves of pseudo terminals. This scheme has a number of problems,
X86_64
including security.

ARM, ARM64, 2.6.23-2.6.39, 3.0-

HIBERNATION=is not set X86_32, 3.19, 4.0-4.20, Do not support hibernation. Allows replacement of running kernel.
X86_64 5.0-5.17

2.6.24-2.6.39, 3.0- If enabled, include code to run legacy 32-bit programs under a 64-bit
X86_32,
IA32_EMULATION=is not set 3.19, 4.0-4.20, kernel. You should likely turn this on, unless you're 100% sure that
X86_64
5.0-5.17 you don't have any 32-bit programs left.

If enabled, include code to run binaries for the x32 native 32-bit ABI
X86_32, 3.9-3.19, 4.0-4.20, for 64-bit processors. An x32 process gets access to the full 64-bit
X86_X32=is not set
X86_64 5.0-5.17 register file and wide data path while leaving pointers at 32 bits for
smaller memory footprint.

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
MODIFY_LDT_SYSCALL=is X86_32,
4.3-4.20, 5.0-5.17 Wine programs. It is also used by some very old threading libraries.
not set X86_64
Enabling this feature adds a small amount of overhead to context
switches and increases the low-level kernel attack surface. Disabling it
removes the modify_ldt(2) system call.

There will be no vsyscall mapping at all. This will eliminate any risk of
X86_32, ASLR bypass due to the vsyscall fixed address mapping. Attempts to
LEGACY_VSYSCALL_NONE=Y 4.4-4.20, 5.0-5.17
X86_64 use the vsyscalls will be reported to dmesg, so that either old or
malicious userspace programs can be identified.

Do not allow older ABI binaries to run on this kernel. If enabled, the
2.6.16-2.6.39, 3.0-
seccomp filter system will not be available, since there is no way yet
OABI_COMPAT=is not set ARM 3.19, 4.0-4.20,
to sensibly distinguish between legacy ABI and newer arm EABI
5.0-5.17
calling conventions during filtering.

ARM, ARM64, Do not enable memory allocator for compressed pages (slab-based
3.16-3.19, 4.0-
ZSMALLOC=is not set X86_32, memory allocator designed to store compressed RAM pages via
4.20, 5.0-5.17
X86_64 virtual memory mapping

ARM, ARM64,
If ZSMALLOC is enabled, be sure not to enable ZSMALLOC_STAT, as
ZSMALLOC_STAT=is not set X86_32, 4.0-4.20, 5.0-5.17
it may leak too much information about ZSMALLOC
X86_64

Timesys Corporation, 2022

[Link]
Expected Conditional Architectures Kernel Versions Note
PAGE_OWNER=is not ARM, ARM64, If enabled, this keeps track of what call chain is the owner of a
5.1-5.17
set X86_32, X86_64 page, may help to find bare alloc_page(s) leaks.

DEBUG_KMEMLEAK=is ARM, ARM64, 2.6.31-2.6.39, 3.0-3.19, 4.0-

Do not enable the memory leak detector.
not set X86_32, X86_64 4.20, 5.0-5.17

BINFMT_AOUT=is not ARM, ARM64, 2.5.73-2.5.75, 2.6.0-2.6.39, Do not enabled support for [Link]/ECOFF binaries. These are
set X86_32, X86_64 3.0-3.19, 4.0-4.20, 5.0-5.17 legacy formats. Everything should be ELF.

ARM, ARM64, 2.6.25-2.6.39, 3.0-3.19, 4.0- If enabled, kprobes allows you to trap at almost any kernel
KPROBES=is not set
X86_32, X86_64 4.20, 5.0-5.17 address and execute a callback function.

ARM, ARM64,
UPROBES=is not set 3.15-3.19, 4.0-4.20, 5.0-5.17 Uprobes is the user-space counterpart to kprobes
X86_32, X86_64

GENERIC_TRACER=is ARM, ARM64, 2.6.31-2.6.39, 3.0-3.19, 4.0-

Do not enable tracing capabilities
not set X86_32, X86_64 4.20, 5.0-5.17

ARM, ARM64, 2.6.27-2.6.39, 3.0-3.19, 4.0-

TRACING=is not set Do not enable tracing capabilities
X86_32, X86_64 4.20, 5.0-5.17

TRACING_SUPPORT=is ARM, ARM64, 2.6.30-2.6.39, 3.0-3.19, 4.0-

Do not enable tracing capabilities
not set X86_32, X86_64 4.20, 5.0-5.17

ARM, ARM64, 2.6.31-2.6.39, 3.0-3.19, 4.0-

FTRACE=is not set Do not enable tracing capabilities
X86_32, X86_64 4.20, 5.0-5.17

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
ARM, ARM64, 2.6.37-2.6.39, 3.0-3.19,
PROC_VMCORE=is not set Do not export the dump image of crashed kernel
X86_32, X86_64 4.0-4.20, 5.0-5.17

PROC_PAGE_MONITOR=is ARM, ARM64, 2.6.28-2.6.39, 3.0-3.19,

Do not expose process memory utilization via /proc interfaces
not set X86_32, X86_64 4.0-4.20, 5.0-5.17

ARM, ARM64, If enabled, this allows the libc5 and earlier dynamic linker
USELIB=is not set 4.5-4.20, 5.0-5.17
X86_32, X86_64 usblib syscall. Should no longer be needed.

CHECKPOINT_RESTORE=is ARM, ARM64, 3.3-3.19, 4.0-4.20, 5.0-

Do not enable checkpoint/restore functionality
not set X86_32, X86_64 5.17

ARM, ARM64, Do not enable the userfaultfd() system call that allows to
USERFAULTFD=is not set 4.3-4.20, 5.0-5.17
X86_32, X86_64 intercept and handle page faults in userland.

HWPOISON_INJECT=is not ARM, ARM64, 2.6.33-2.6.39, 3.0-3.19, Do not enable the hwpoison injector, which intentionally
set X86_32, X86_64 4.0-4.20, 5.0-5.17 triggers a hwpoison memory failure

MEM_SOFT_DIRTY=is not ARM, ARM64, 3.11-3.19, 4.0-4.20, 5.0- Do not enable tracking of memory changes (by introducing a
set X86_32, X86_64 5.17 soft-dirty bit on pte-s)

ARM, ARM64,
DEVPORT=is not set 4.11-4.20, 5.0-5.17 Do not enable /dev/port interface
X86_32, X86_64

ARM, ARM64, 2.6.11-2.6.39, 3.0-3.19,

DEBUG_FS=is not set Do not enable debugfs, as it may expose vulnerabilities
X86_32, X86_64 4.0-4.20, 5.0-5.17

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
ARM, ARM64, If enabled, this option provides the ability to inject artificial errors to
NOTIFIER_ERROR_INJECTION=is 3.6-3.19, 4.0-4.20,
X86_32, specified notifier chain callbacks. It is useful to test the error
not set 5.0-5.17
X86_64 handling of notifier call chain failures.

2.6.26-2.6.39, 3.0-
X86_32,
X86_PTDUMP=is not set 3.19, 4.0-4.4, 4.5- Export kernel pagetable layout to userspace via debugfs.
X86_64
4.20, 5.0-5.5, 5.5

ARM, ARM64,
PTDUMP_DEBUGFS=is not set X86_32, 5.6-5.17 Do not show the kernel pagetable layout in a debugfs file
X86_64

ARM, ARM64, Enable legacy DRI1 drivers. Those drivers expose unsafe and
DRM_LEGACY=is not set X86_32, 4.9-4.20, 5.0-5.17 dangerous APIs to user-space, which can be used to circumvent
X86_64 access restrictions and other security measures.

ARM, ARM64, 2.6.12-2.6.39, 3.0-

Old display system which does not use modern security practices,
FB=is not set X86_32, 3.19, 4.0-4.20,
could be exploitable
X86_64 5.0-5.17

ARM, ARM64,
2.6.39, 3.0-3.19,
VT=is not set X86_32, Do not enable virtual terminal devices
4.0-4.20, 5.0-5.17
X86_64

ARM, ARM64, 2.6.28-2.6.39, 3.0-

SELinux W+X protections have been bypassed by AIO before
AIO=is not set X86_32, 3.19, 4.0-4.20,
([Link]
X86_64 5.0-5.17

If enabled, this option allows you to select a number of drivers that

are not of the "normal" Linux kernel quality level. These drivers are
ARM, ARM64, 2.6.28-2.6.39, 3.0-
placed here in order to get a wider audience to make use of them.
STAGING=is not set X86_32, 3.19, 4.0-4.20,
Please note that these drivers are under heavy development, may
X86_64 5.0-5.17
or may not work, and may contain userspace interfaces that most
likely will be changed in the near future.

ARM, ARM64, 2.6.32-2.6.39, 3.0-

Do not enable kernel same page merging, as sharing memory
KSM=is not set X86_32, 3.19, 4.0-4.20,
spaces can be exploitable
X86_64 5.0-5.17

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
ARM, ARM64, 2.6.20-2.6.39, 3.0-
KALLSYMS=is not set X86_32, 3.19, 4.0-4.20, Do not load/print debug/symbolic crash information
X86_64 5.0-5.17

X86_VSYSCALL_EMULATION=is X86_32, 3.19, 4.0-4.20,

If set, this enables emulation of the legacy vsyscall page.
not set X86_64 5.0-5.17

ARM, ARM64, 2.6.9-2.6.39, 3.0-

Disable, as sysrq keys could give someone too much access to the
MAGIC_SYSRQ=is not set X86_32, 3.19, 4.0-4.20,
system, especially after a system crash
X86_64 5.0-5.17

ARM, ARM64, Potentially exploitable to gain root privileges. If enabled, this allows
3.9-3.19, 4.0-4.20,
USER_NS=is not set X86_32, containers to use user namespaces to provide different user info to
5.0-5.17
X86_64 each container.

This device gives privileged processes access to the x86 Model-

2.6.24-2.6.39, 3.0- Specific Registers (MSRs). It is a character device with major 202
X86_32,
X86_MSR=is not set 3.19, 4.0-4.20, and minors 0 to 31 for /dev/cpu/0/msr to /dev/cpu/31/msr. MSR
X86_64
5.0-5.17 accesses are directed to a specific CPU on multi-processor
systems.

This device gives processes access to the x86 CPUID instruction to

2.6.24-2.6.39, 3.0-
X86_32, be executed on a specific processor. It is a character device with
X86_CPUID=is not set 3.19, 4.0-4.20,
X86_64 major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
5.0-5.17
/dev/cpu/31/cpuid.

X86_32, This enables the ioperm() and iopl() syscalls which are necessary
X86_IOPL_IOPERM=is not set 5.5-5.17
X86_64 for legacy applications.

X86_32, TSX is disabled if possible - equals to tsx=off command line

X86_INTEL_TSX_MODE_OFF=Y 5.4-5.17
X86_64 parameter.

ARM, ARM64,
Do not automatically load TTY line disciplines, as they could
LDISC_AUTOLOAD=is not set X86_32, 5.1-5.17
potentially be exploitable
X86_64

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
ARM, ARM64, If set, this option enables support for the io_uring interface, enabling
IO_URING=is not set X86_32, 5.1-5.17 applications to submit and complete IO through submission and
X86_64 completion rings that are shared between the kernel and application

ARM, ARM64,
ACPI_TABLE_UPGRADE=is
X86_32, 4.7-4.20, 5.0-5.17 Do not allow ACPI tables to be passed in via initrd
not set
X86_64

ARM, ARM64,
EFI_TEST=is not set X86_32, 4.9-4.20, 5.0-5.17 Do not provide EFI Runtime Service Tests Support
X86_64

ARM, ARM64,
3.18-3.19, 4.0- Do not enable bpf() system call (to manipulate eBPF programs and maps)
BPF_SYSCALL=is not set X86_32,
4.20, 5.0-5.17 unless expliticitly necessary
X86_64

ARM, ARM64, 2.6.29-2.6.39, 3.0-

MMIOTRACE_TEST=is not This is a dumb module for testing mmiotrace. It is very dangerous as it
X86_32, 3.19, 4.0-4.20,
set will write garbage to IO memory starting at a given address.
X86_64 5.0-5.17

ARM, ARM64, 2.6.29-2.6.39, 3.0- Mmiotrace traces Memory Mapped I/O access and is meant for
MMIOTRACE=is not set X86_32, 3.19, 4.0-4.20, debugging and reverse engineering. It is called from the ioremap
X86_64 5.0-5.17 implementation and works via page faults.

ARM, ARM64,
LIVEPATCH=is not set X86_32, 4.0-4.20, 5.0-5.17 Do not support kernel live patching, as it could be exploitable
X86_64

ARM, ARM64,
3.9-3.19, 4.0-4.20,
IP_DCCP=is not set X86_32, Do not enable DCCP protocol unless explicitly needed
5.0-5.17
X86_64

ARM, ARM64,
3.8-3.19, 4.0-4.20,
IP_SCTP=is not set X86_32, Do not enable SCTP protocol unless explicitly needed
5.0-5.17
X86_64

Timesys Corporation, 2022

[Link]
Expected Conditional Architectures Kernel Versions Note
ARM, ARM64,
3.0-3.19, 4.0-4.20,
BPF_JIT=is not set X86_32, Do not allow just in time compilation for Berkeley Packet Filtering
5.0-5.17
X86_64

ARM, ARM64,
VIDEO_VIVID=is not set X86_32, 5.17 Do not enable virtual video test driver
X86_64

2.5.45-2.5.75,
ARM, ARM64,
2.6.0-2.6.39, 3.0-
INPUT_EVBUG=is not set X86_32, Do not log input subsystem events (could be used as a keylogger, etc)
3.19, 4.0-4.20,
X86_64
5.0-5.17

ARM, ARM64,
PANIC_ON_OOPS=is not 3.5-3.19, 4.0-4.20, Reboot devices immediately if kernel experiences an Oops. (must also set
X86_32,
set 5.0-5.17 CONFIG_PANIC_TIMEOUT)
X86_64

ARM, ARM64,
3.14-3.19, 4.0- Reboot devices immediately if kernel experiences an Oops. (must also set
PANIC_TIMEOUT=-1 X86_32,
4.20, 5.0-5.17 CONFIG_PANIC_ON_OOPS)
X86_64

This option allows for unused exported symbols to be dropped from the
ARM, ARM64,
build. In turn, this provides the compiler more opportunities (especially
TRIM_UNUSED_KSYMS=Y X86_32, 4.7-4.20, 5.0-5.17
when using LTO) for optimizing the code and reducing binary size. This
X86_64
might have some security advantages as well.

2.5.45-2.5.75,
ARM, ARM64,
2.6.0-2.6.39, 3.0-
BLK_DEV_FD=is not set X86_32, This option enables the use of floppy disk drive(s) of your PC.
3.19, 4.0-4.20,
X86_64
5.0-5.17

This is a debug driver, which gets the power states of all Punit North
PUNIT_ATOM_DEBUG=is X86_32, Complex devices. The power states of each device is exposed as part of
4.2-4.20, 5.0-5.17
not set X86_64 the debugfs interface. The current power state can be read from
/sys/kernel/debug/punit_atom/dev_power_state

ARM, ARM64, Select this option to enable support for ACPI configuration from userspace.
ACPI_CONFIGFS=is not
X86_32, 4.8-4.20, 5.0-5.17 The configurable ACPI groups will be visible under /config/acpi, assuming
set
X86_64 configfs is mounted under /config.

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
This turns on debugging information for the entire EDAC
ARM, ARM64, 2.6.16-2.6.39, 3.0-
subsystem. You do so by inserting edac_module with
EDAC_DEBUG=is not set X86_32, 3.19, 4.0-4.20,
"edac_debug_level=x." Valid levels are 0-4 (from low to high) and
X86_64 5.0-5.17
by default it is set to 2. Usually you should select 'N' here.

X86_32, Choose this option to turn on extra driver debugging that may affect
DRM_I915_DEBUG=is not set 4.7-4.20, 5.0-5.17
X86_64 performance but will catch some internal issues.

ARM, ARM64, Keeps all active closures in a linked list and provides a debugfs
BCACHE_CLOSURES_DEBUG=is 3.10-3.19, 4.0-
X86_32, interface to list them, which makes it possible to see asynchronous
not set 4.20, 5.0-5.17
X86_64 operations that get stuck.

This adds support for DVB front-end cards connected to TS inputs

DVB_C8SECTPFE=is not set ARM, ARM64 4.3-4.20, 5.0-5.17
of STiH407/410 SoC.

2.5.45-2.5.75,
ARM, ARM64, If your CPU cannot cache all of the physical memory in your
2.6.0-2.6.39, 3.0-
MTD_SLRAM=is not set X86_32, machine, you can still use it for storage or swap by using this driver
3.19, 4.0-4.20,
X86_64 to present it to the system as a Memory Technology Device.
5.0-5.17

This is a re-implementation of the slram driver above. Use this

ARM, ARM64, 2.6.8-2.6.39, 3.0-
driver to access physical memory that the kernel proper doesn't
MTD_PHRAM=is not set X86_32, 3.19, 4.0-4.20,
have access to, memory beyond the mem=xxx limit, nvram,
X86_64 5.0-5.17
memory on the video card, etc...

ARM, ARM64,
4.11-4.20, 5.0- This allows the user to add tracing events (similar to tracepoints) on
KPROBE_EVENTS=is not set X86_32,
5.17 the fly via the ftrace interface.
X86_64

ARM, ARM64, This allows the user to add tracing events on top of userspace
4.11-4.20, 5.0-
UPROBE_EVENTS=is not set X86_32, dynamic events (similar to tracepoints) on the fly via the trace
5.17
X86_64 events interface.

ARM, ARM64, 2.6.28-2.6.39, 3.0-

FUNCTION_TRACER=is not set X86_32, 3.19, 4.0-4.20, Enable the kernel to trace every kernel function.
X86_64 5.0-5.17

Timesys Corporation, 2022

[Link]
 Expected Conditional Architectures Kernel Versions Note
ARM, ARM64, 2.6.28-2.6.39, 3.0-
This special tracer records the maximum stack footprint of the
STACK_TRACER=is not set X86_32, 3.19, 4.0-4.20,
kernel and displays it in /sys/kernel/debug/tracing/stack_trace.
X86_64 5.0-5.17

ARM, ARM64, Allow one or more arbitrary trace event fields to be aggregated
HIST_TRIGGERS=is not set X86_32, 4.7-4.20, 5.0-5.17 into hash tables and dumped to stdout by reading a
X86_64 debugfs/tracefs file.

ARM, ARM64, 2.6.33-2.6.39, 3.0- Say Y here if you want to be able to trace the block layer actions
BLK_DEV_IO_TRACE=is not set X86_32, 3.19, 4.0-4.20, on a given queue. Tracing allows you to see any traffic happening
X86_64 5.0-5.17 on a block device queue.

ARM, ARM64,
FAIL_FUTEX=is not set X86_32, 4.3-4.20, 5.0-5.17 Provide fault-injection capability for futexes.
X86_64

Enable the kernel resource comparison system call. It provides

ARM, ARM64,
user-space with the ability to compare two processes to see if
KCMP=is not set X86_32, 5.12-5.17
they share a common resource, such as a file descriptor or even
X86_64
virtual memory space.

Enable the restartable sequences system call. It provides a user-

ARM, ARM64,
4.18-4.20, 5.0- space cache for the current CPU number value, which speeds up
RSEQ=is not set X86_32,
5.17 getting the current CPU number from user-space, as well as an
X86_64
ABI to speed up user-space operations on per-CPU data.

ARM, ARM64, 2.6.25-2.6.39, 3.0-

Enable this option if you want to use the LatencyTOP tool to find
LATENCYTOP=is not set X86_32, 3.19, 4.0-4.20,
out which userspace is blocking on what kernel operations.
X86_64 5.0-5.17

ARM, ARM64,
KCOV exposes kernel code coverage information in a form
KCOV=is not set X86_32, 4.6-4.20, 5.0-5.17
suitable for coverage-guided fuzzing (randomized testing).
X86_64

If you want to debug problems which hang or crash the kernel

ARM, ARM64, 2.6.26-2.6.39, 3.0-
PROVIDE_OHCI1394_DMA_INIT=is early on boot and the crashing machine has a FireWire port, you
X86_32, 3.19, 4.0-4.20,
not set can use this feature to remotely access the memory of the
X86_64 5.0-5.17
crashed machine over FireWire.

Timesys Corporation, 2022

[Link]
Expected Conditional Architectures Kernel Versions Note
ARM, ARM64, This option enables a sysctl-based debugging interface that is be used by the
SUNRPC_DEBUG=is 3.4-3.19, 4.0-4.20,
X86_32, rpcdebug utility to turn on or off logging of different aspects of the kernel RPC
not set 5.0-5.17
X86_64 activity.

There are inherent limitations and complexities that make IMA/EVM more
ARM, ARM64, 2.6.30-2.6.39, 3.0-
difficult to implement than DM_VERITY. Timesys suggests using DM_VERITY
IMA=Y X86_32, 3.19, 4.0-4.20,
instead. Filesystem Hardening (Integirty Measurement Architecture, file level)
X86_64 5.0-5.17
- Requires userspace support

There are inherent limitations and complexities that make IMA/EVM more
ARM, ARM64,
3.2-3.19, 4.0-4.20, difficult to implement than DM_VERITY. Timesys suggests using DM_VERITY
EVM=Y X86_32,
5.0-5.17 instead. Filesystem Hardening (Extended Verification Module, file level) -
X86_64
Requires userspace support

ARM, ARM64,
3.9-3.19, 4.0-4.20, Filesystem Hardening (Block Level Verification via dm-verity) - Requires
DM_VERITY=Y X86_32,
5.0-5.17 userspace support
X86_64

ARM, ARM64, 2.6.4-2.6.39, 3.0-

Filesystem Hardening (Block Level Encryption via dm-crypt) - Requires
DM_CRYPT=Y X86_32, 3.19, 4.0-4.20,
userspace support
X86_64 5.0-5.17

ARM, ARM64, Filesystem Hardening (Verification via dm-integrity) - Requires userspace

4.12-4.20, 5.0-
DM_INTEGRITY=Y X86_32, support. Provides a lighter weight read-write block level integrity protection for
5.17
X86_64 file systems not requiring full disk encryption, but which do require writability

Timesys Corporation, 2022

[Link]