1 .. Copyright © 2018 ANSSI.
2 CLIP OS is a trademark of the French Republic.
3 Content licensed under the Open License version 2.0 as published by Etalab
4 (French task force for Open Data).
11 The CLIP OS kernel is based on Linux. It also integrates:
13 * existing hardening patches that are not upstream yet and that we consider
14 relevant to our security model;
15 * developments made for previous CLIP OS versions that we have not upstreamed
16 yet (or that cannot be);
17 * entirely new functionalities that have not been upstreamed yet (or that
23 As the core of a hardened operating system, the CLIP OS kernel is particularly
26 * providing **robust security mechanisms** to higher levels of the operating
27 system, such as reliable isolation primitives;
28 * maintaining maximal **trust in hardware resources**;
29 * guaranteeing its **own protection** against various threats.
34 In this section we discuss our security-relevant configuration choices for
35 the CLIP OS kernel. Before starting, it is worth mentioning that:
37 * We do our best to **limit the number of kernel modules**.
39 In other words, as many modules as possible should be built-in. Modules are
40 only used when needed either for the initramfs or to ease the automation of
41 the deployment of CLIP OS on multiple different machines (for the moment, we
42 only target a QEMU-KVM guest). This is particularly important as module
43 loading is disabled after CLIP OS startup.
45 * We **focus on a secure configuration**. The remaining of the configuration
46 is minimal and it is your job to tune it for your machines and use cases.
48 * CLIP OS only supports the x86-64 architecture for now.
50 * Running 32-bit programs is voluntarily unsupported. Should you change that
51 in your custom kernel, keep in mind that it requires further attention when
52 configuring it (e.g., ensure that ``CONFIG_COMPAT_VDSO=n``).
54 * Many options that are not useful to us are disabled in order to cut attack
55 surface. As they are not all detailed below, please see
56 ``src/portage/clip/sys-kernel/clipos-kernel/files/config.d/blacklist`` for an
57 exhaustive list of the ones we **explicitly** disable.
62 .. describe:: CONFIG_AUDIT=y
64 CLIP OS will need the auditing infrastructure.
66 .. describe:: CONFIG_IKCONFIG=n
68 We do not need ``.config`` to be available at runtime.
70 .. describe:: CONFIG_KALLSYMS=n
72 Symbols are only useful for debug and attack purposes.
74 .. describe:: CONFIG_EXPERT=y
76 This unlocks additional configuration options we need.
80 .. describe:: CONFIG_USER_NS=n
82 User namespaces can be useful for some use cases but even more to an
83 attacker. We choose to disable them for the moment, but we could also enable
84 them and use the ``kernel.unprivileged_userns_clone`` sysctl provided by
85 linux-hardened to disable their unprivileged use.
89 .. describe:: CONFIG_SLUB_DEBUG=y
91 Allow allocator validation checking to be enabled.
93 .. describe:: CONFIG_SLAB_MERGE_DEFAULT=n
95 Merging SLAB caches can make heap exploitation easier.
97 .. describe:: CONFIG_SLAB_FREELIST_RANDOM=y
99 Randomize allocator freelists
101 .. describe:: CONFIG_SLAB_FREELIST_HARDENED=y
105 .. describe:: CONFIG_SLAB_HARDENED=y
107 Add various little checks to harden the slab allocator. [linux-hardened]_
109 .. describe:: CONFIG_SLAB_CANARY=y
111 Place canaries at the end of slab allocations. [linux-hardened]_
113 .. describe:: CONFIG_SLAB_SANITIZE=y
115 Zero-fill slab allocations on free to reduce risks of information leaks and
116 help mitigate use-after-free vulnerabilities. [linux-hardened]_
118 .. describe:: CONFIG_SLAB_SANITIZE_VERIFY=y
120 Verify that newly allocated slab allocations are zeroed to detect
121 write-after-free bugs. [linux-hardened]_
126 .. describe:: CONFIG_COMPAT_BRK=n
128 Enabling this would disable brk ASLR.
132 .. describe:: CONFIG_GCC_PLUGINS=y
134 Enable GCC plugins, some of which are security-relevant; GCC 4.7 at least is
137 .. describe:: CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y
139 Instrument some kernel code to gather additional (but not
140 cryptographically secure) entropy at boot time.
142 .. describe:: CONFIG_GCC_PLUGIN_STRUCTLEAK=y
144 Prevent potential information leakage by forcing initialization of
145 structures containing userspace addresses. This is particularly
146 important to prevent trivial bypassing of KASLR.
148 .. describe:: CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y
150 Extend forced initialization to all local structures that have their
151 address taken at any point.
153 .. describe:: CONFIG_GCC_PLUGIN_RANDSTRUCT=y
155 Randomize layout of sensitive kernel structures. Exploits targeting such
156 structures then require an additional information leak vulnerability.
158 .. describe:: CONFIG_GCC_PLUGIN_RANDSTRUCT_PERFORMANCE=n
160 Do not weaken structure randomization
164 .. describe:: CONFIG_ARCH_MMAP_RND_BITS=32
166 Use maximum number of randomized bits for the mmap base address on x86_64.
167 Note that thanks to a linux-hardened patch, this also impacts the number of
168 randomized bits for the stack base address.
172 .. describe:: CONFIG_STACKPROTECTOR=y
173 CONFIG_STACKPROTECTOR_STRONG=y
175 Use ``-fstack-protector-strong`` for best stack canary coverage; GCC 4.9 at
178 .. describe:: CONFIG_VMAP_STACK=y
180 Virtually-mapped stacks benefit from guard pages, thus making kernel stack
181 overflows harder to exploit.
183 .. describe:: CONFIG_REFCOUNT_FULL=y
185 Do extensive checks on reference counting to prevent use-after-free
186 conditions. Without this option, on x86, there already is a fast
187 assembly-based protection based on the PaX implementation but it does not
192 .. describe:: CONFIG_STRICT_MODULE_RWX=y
194 Enforce strict memory mappings permissions for loadable kernel modules.
198 Although CLIP OS stores kernel modules in a read-only rootfs whose integrity is
199 guaranteed by dm-verity, we still enable and enforce module signing as an
200 additional layer of security:
202 .. describe:: CONFIG_MODULE_SIG=y
203 CONFIG_MODULE_SIG_FORCE=y
204 CONFIG_MODULE_SIG_ALL=y
205 CONFIG_MODULE_SIG_SHA512=y
206 CONFIG_MODULE_SIG_HASH="sha512"
210 .. describe:: CONFIG_LOCAL_INIT=n
212 This option requires compiler support for ``-fsanitize=local-init``, which
213 is only available in Clang. [linux-hardened]_
215 Processor type and features
216 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
218 .. describe:: CONFIG_RETPOLINE=y
220 Retpolines are needed to protect against Spectre v2. GCC 7.3.0 or higher is
223 .. describe:: CONFIG_LEGACY_VSYSCALL_NONE=y
225 The vsyscall table is not required anymore by libc and is a fixed-position
226 potential source of ROP gadgets.
228 .. describe:: CONFIG_X86_VSYSCALL_EMULATION=n
232 .. describe:: CONFIG_MICROCODE=y
234 Needed to benefit from microcode updates and thus security fixes (e.g.,
235 additional Intel pseudo-MSRs to be used by the kernel as a mitigation for
236 various speculative execution vulnerabilities).
238 .. describe:: CONFIG_X86_MSR=y
240 See above explanation about ``CONFIG_MICROCODE``.
242 .. describe:: CONFIG_KSM=n
244 Enabling this feature can make cache side-channel attacks such as
245 FLUSH+RELOAD much easier to carry out.
249 .. describe:: CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
251 This should in particular be non-zero to prevent the exploitation of kernel
254 .. describe:: CONFIG_MTRR=y
256 Memory Type Range Registers can make speculative execution bugs a bit harder
259 .. describe:: CONFIG_X86_PAT=y
261 Page Attribute Tables are the modern equivalents of MTRRs, which we
264 .. describe:: CONFIG_ARCH_RANDOM=y
266 Enable the RDRAND instruction to benefit from a secure hardware RNG if
267 supported. See ``CONFIG_RANDOM_TRUST_CPU`` for warnings about that.
269 .. describe:: CONFIG_X86_SMAP=y
271 Enable Supervisor Mode Access Prevention to prevent ret2usr exploitation
274 .. describe:: CONFIG_X86_INTEL_UMIP=y
276 Enable User Mode Instruction Prevention. Note that hardware supporting this
277 feature is not common yet.
279 .. describe:: CONFIG_X86_INTEL_MPX=n
281 Intel Memory Protection Extensions add hardware assistance to memory
282 protection. Compiler support is required but is deprecated in GCC 8 and will
283 probably be dropped in GCC 9.
285 .. describe:: CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS=n
287 Memory Protection Keys are a promising feature but they are still not
288 supported on current hardware.
292 Enable the **seccomp** BPF userspace API for syscall attack surface reduction:
294 .. describe:: CONFIG_SECCOMP=y
295 CONFIG_SECCOMP_FILTER=y
299 .. describe:: CONFIG_RANDOMIZE_BASE=y
301 While this may be seen as a `controversial
302 <https://grsecurity.net/kaslr_an_exercise_in_cargo_cult_security.php>`_
303 feature, it makes sense for CLIP OS. Indeed, KASLR may be defeated thanks to
304 the kernel interfaces that are available to an attacker, or through attacks
305 leveraging hardware vulnerabilities such as speculative and out-of-order
306 execution ones. However, CLIP OS follows the *defense in depth* principle
307 and an attack surface reduction approach. Thus, the following points make
308 KASLR relevant in the CLIP OS kernel:
310 * KASLR was initially designed to counter remote attacks but the strong
311 security model of CLIP OS (e.g., no sysfs mounts in most containers,
312 minimal procfs, no arbitrary code execution) makes a local attack
313 more complex to carry out.
314 * STRUCTLEAK, STACKLEAK, kptr_restrict and
315 ``CONFIG_SECURITY_DMESG_RESTRICT`` are enabled in CLIP OS.
316 * The CLIP OS kernel is custom-compiled (at least for a given deployment),
317 its image is unreadable to all users including privileged ones and updates
318 are end-to-end encrypted. This makes both the content and addresses of the
319 kernel image secret. Note that, however, the production kernel image is
320 currently part of an EFI binary and is not encrypted, causing it to be
321 accessible to a physical attacker. This will change in the future as we
322 will only use the kernel included in the EFI binary to boot and then
323 *kexec* to the real production kernel whose image will be located on an
324 encrypted disk partition.
325 * We enable ``CONFIG_PANIC_ON_OOPS`` by default so that the kernel
326 cannot recover from failed exploit attempts, thus preventing any brute
328 * We enable Kernel Page Table Isolation, mitigating Meltdown and potential
329 other hardware information leakage. Variante 3a (Rogue System Register
330 Read) however remains an important threat to KASLR.
334 .. describe:: CONFIG_RANDOMIZE_MEMORY=y
336 Most of the above explanations stand for that feature.
338 .. describe:: CONFIG_KEXEC=n
341 Disable the ``kexec()`` system call to prevent an already-root attacker from
342 rebooting on an untrusted kernel.
344 .. describe:: CONFIG_CRASH_DUMP=n
346 A crash dump can potentially provide an attacker with useful information.
347 However we disabled ``kexec()`` syscalls above thus this configuration
348 option should have no impact anyway.
352 .. describe:: CONFIG_MODIFY_LDT_SYSCALL=n
354 This is not supposed to be needed by userspace applications and only
355 increases the kernel attack surface.
357 Power management and ACPI options
358 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
360 .. describe:: CONFIG_HIBERNATION=n
362 The CLIP OS swap partition is encrypted with an ephemeral key and thus
363 cannot support suspend to disk.
368 .. describe:: CONFIG_RESET_ATTACK_MITIGATION=n
370 In order to work properly, this mitigation requires userspace support that
371 is currently not available in CLIP OS. Moreover, due to our use of Secure
372 Boot, Trusted Boot and the fact that machines running CLIP OS are expected
373 to lock their BIOS with a password, the type of *cold boot attacks* this
374 mitigation is supposed to thwart should not be an issue.
376 Executable file formats / Emulations
377 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
379 .. describe:: CONFIG_BINFMT_MISC=n
381 We do not want our kernel to support miscellaneous binary classes. ELF
382 binaries and interpreted scripts starting with a shebang are enough.
384 .. describe:: CONFIG_COREDUMP=n
386 Core dumps can provide an attacker with useful information.
391 .. describe:: CONFIG_SYN_COOKIES=y
393 Enable TCP syncookies.
398 .. describe:: CONFIG_TCG_TPM=n
400 TPM use is not supported by CLIP OS yet.
402 .. describe:: CONFIG_DEVMEM=n
404 The ``/dev/mem`` device should not be required by any user application
409 If you must enable it, at least enable ``CONFIG_STRICT_DEVMEM`` and
410 ``CONFIG_IO_STRICT_DEVMEM`` to restrict at best access to this device.
412 .. describe:: CONFIG_DEVKMEM=n
414 This virtual device is only useful for debug purposes and is very dangerous
415 as it allows direct kernel memory writing (particularly useful for
418 .. describe:: CONFIG_LEGACY_PTYS=n
420 Use the modern PTY interface only.
422 .. describe:: CONFIG_DEVPORT=n
424 The ``/dev/port`` device should not be used anymore by userspace, and it
425 could increase the kernel attack surface.
427 .. describe:: CONFIG_RANDOM_TRUST_CPU=n
429 Do not rely exclusively on the hardware RNG provided by the CPU manufacturer
430 to initialize Linux's CRNG, as we do not mind blocking a bit more at boot
431 time while additional entropy sources are mixed in.
433 The IOMMU allows for protecting the system's main memory from arbitrary
434 accesses from devices (e.g., DMA attacks). Note that this is related to
435 hardware features. On a recent Intel machine, we enable the following:
437 .. describe:: CONFIG_IOMMU_SUPPORT=y
439 CONFIG_INTEL_IOMMU_SVM=y
440 CONFIG_INTEL_IOMMU_DEFAULT_ON=y
445 .. describe:: CONFIG_PROC_KCORE=n
447 Enabling this would provide an attacker with precious information on the
453 .. describe:: CONFIG_MAGIC_SYSRQ=n
455 This should only be needed for debugging.
457 .. describe:: CONFIG_DEBUG_KERNEL=y
459 This is useful even in a production kernel to enable further configuration
460 options that have security benefits.
462 .. describe:: CONFIG_DEBUG_VIRTUAL=y
464 Enable sanity checks in virtual to page code.
466 .. describe:: CONFIG_STRICT_KERNEL_RWX=y
468 Ensure kernel page tables have strict permissions.
470 .. describe:: CONFIG_DEBUG_WX=y
472 Check and report any dangerous memory mapping permissions, i.e., both
473 writable and executable kernel pages.
475 .. describe:: CONFIG_DEBUG_FS=n
477 The debugfs virtual file system is only useful for debugging and protecting
478 it would require additional work.
480 .. describe:: CONFIG_SLUB_DEBUG_ON=n
482 Using the ``slub_debug`` command line parameter provides more fine grained
485 .. describe:: CONFIG_PANIC_ON_OOPS=y
486 CONFIG_PANIC_TIMEOUT=-1
488 Prevent potential further exploitation of a bug by immediately panicking the
491 The following options add additional checks and validation for various
492 commonly targeted kernel structures:
494 .. describe:: CONFIG_DEBUG_CREDENTIALS=y
495 CONFIG_DEBUG_NOTIFIERS=y
498 .. describe:: CONFIG_BUG_ON_DATA_CORRUPTION=y
500 Note that linux-hardened patches add more places where this configuration
501 option has an impact.
503 .. describe:: CONFIG_SCHED_STACK_END_CHECK=y
504 .. describe:: CONFIG_PAGE_POISONING=n
506 We choose to poison pages with zeroes and thus prefer using the simpler
507 PaX-based implementation provided by linux-hardened (see
508 ``CONFIG_PAGE_SANITIZE`` below).
513 .. describe:: CONFIG_SECURITY_DMESG_RESTRICT=y
515 Prevent unprivileged users from gathering information from the kernel log
516 buffer via ``dmesg(8)``. Note that this still can be overridden through the
517 ``kernel.dmesg_restrict`` sysctl.
519 .. describe:: CONFIG_PAGE_TABLE_ISOLATION=y
521 Enable KPTI to prevent Meltdown attacks and, more generally, reduce the
522 number of hardware side channels.
526 .. describe:: CONFIG_INTEL_TXT=n
528 CLIP OS does not use Intel Trusted Execution Technology.
532 .. describe:: CONFIG_HARDENED_USERCOPY=y
534 Harden data copies between kernel and user spaces, preventing classes of
535 heap overflow exploits and information leaks.
537 .. describe:: CONFIG_HARDENED_USERCOPY_FALLBACK=n
539 Use strict whitelisting mode, i.e., do not ``WARN()``.
541 .. describe:: CONFIG_FORTIFY_SOURCE=y
543 Leverage compiler to detect buffer overflows.
545 .. describe:: CONFIG_FORTIFY_SOURCE_STRICT_STRING=n
547 This extends ``FORTIFY_SOURCE`` to intra-object overflow checking. It is
548 useful to find bugs but not recommended for a production kernel yet.
551 .. describe:: CONFIG_STATIC_USERMODEHELPER=y
553 This makes the kernel route all usermode helper calls to a single binary
554 that cannot have its name changed. Without this, the kernel can be tricked
555 into calling an attacker-controlled binary (e.g. to bypass SMAP, cf.
556 `exploitation <https://seclists.org/oss-sec/2016/q4/621>`_ of
559 .. describe:: CONFIG_STATIC_USERMODEHELPER_PATH=""
561 Currently, we have no need for usermode helpers therefore we simply
562 disable them. If we ever need some, this path will need to be set to a
563 custom trusted binary in charge of filtering and choosing what real
564 helpers should then be called.
568 .. describe:: CONFIG_SECURITY=y
570 Enable us to choose different security modules.
572 .. describe:: CONFIG_SECURITY_SELINUX=y
574 CLIP OS intends to leverage SELinux in its security model.
576 .. describe:: CONFIG_SECURITY_SELINUX_BOOTPARAM=n
578 We do not need SELinux to be disableable.
580 .. describe:: CONFIG_SECURITY_SELINUX_DISABLE=n
582 We do not want SELinux to be disabled. In addition, this would prevent LSM
583 structures such as security hooks from being marked as read-only.
585 .. describe:: CONFIG_SECURITY_SELINUX_DEVELOP=y
587 For now, but will eventually be ``n``.
591 .. describe:: DEFAULT_SECURITY_DAC=y
593 The default security module will be changed to SELinux once CLIP OS fully
598 .. describe:: CONFIG_SECURITY_YAMA=y
600 The Yama LSM currently provides ptrace scope restriction (which might be
601 redundant with CLIP-LSM in the future).
605 .. describe:: CONFIG_INTEGRITY=n
607 The integrity subsystem provides several components, the security benefits
608 of which are already enforced by CLIP OS (e.g., read-only mounts for all
609 parts of the system containing executable programs).
613 .. describe:: CONFIG_SECURITY_PERF_EVENTS_RESTRICT=y
615 See documentation about the ``kernel.perf_event_paranoid`` sysctl below.
620 .. describe:: CONFIG_PAGE_SANITIZE=y
622 Zero-fill page allocations on free to reduce risks of information leaks and
623 help mitigate a subset of use-after-free vulnerabilities. This is a simpler
624 equivalent to upstream's ``CONFIG_PAGE_POISONING_ZERO``. [linux-hardened]_
626 .. describe:: CONFIG_PAGE_SANITIZE_VERIFY=y
628 Verify that newly allocated pages are zeroed to detect write-after-free
629 bugs. [linux-hardened]_
633 .. describe:: CONFIG_SECURITY_TIOCSTI_RESTRICT=y
635 This prevents unprivileged users from using the TIOCSTI ioctl to inject
636 commands into other processes which share a tty session. [linux-hardened]_
638 We incorporated most of the *Lockdown* patch series into the CLIP OS kernel,
639 though it may be merged into the mainline kernel in the near future.
640 Basically, *Lockdown* tries to disable many mechanisms that could allow the
641 superuser to eventually run untrusted code in kernel mode (note that a
642 significant portion of them are already disabled in the CLIP OS kernel due to
643 our custom configuration). This is an interesting work for CLIP OS as we want
644 to avoid persistence on a compromised machine even in the case of an
645 already-root attacker. Among the several configuration options brought by
646 *Lockdown*, we enable the following ones:
648 .. describe:: CONFIG_LOCK_DOWN_KERNEL=y
649 CONFIG_LOCK_DOWN_MANDATORY=y
651 Similarly, we incorporated the *STACKLEAK* feature ported from grsecurity/PaX
652 by Alexander Popov and which should be merged upstream ultimately. *STACKLEAK*
653 erases the kernel stack before returning from system calls in order to reduce
654 the information which kernel stack leak bugs can reveal. It also blocks kernel
655 stack depth overflows caused by ``alloca()``, such as Stack Clash attacks.
657 .. describe:: CONFIG_GCC_PLUGIN_STACKLEAK=y
658 CONFIG_STACKLEAK_TRACK_MIN_SIZE=100
659 CONFIG_STACKLEAK_METRICS=n
660 CONFIG_STACKLEAK_RUNTIME_DISABLE=n
666 GCC version 7.3.0 or higher is required to fully benefit from retpolines
667 (``-mindirect-branch=thunk-extern``).
670 Sysctl Security Tuning
671 ----------------------
673 Many sysctls are not security-relevant or only play a role if some kernel
674 configuration options are enabled/disabled. In other words, the following is
675 tightly related to the CLIP OS kernel configuration detailed above.
677 .. describe:: kernel.kptr_restrict = 2
679 Hide kernel addresses in ``/proc`` and other interfaces, even to privileged
682 .. describe:: kernel.yama.ptrace_scope = 3
684 Enable the strictest ptrace scope restriction provided by the Yama LSM.
686 .. describe:: kernel.perf_event_paranoid = 3
688 This completely disallows unprivileged access to the ``perf_event_open()``
689 system call. Note that this requires a patch included in linux-hardened (see
690 `here <https://lwn.net/Articles/696216/>`_ for the reason why it is not
691 upstream), otherwise it is the same as setting this sysctl to ``2``. This is
692 actually not needed as we already enable
693 ``CONFIG_SECURITY_PERF_EVENTS_RESTRICT``.
695 .. describe:: kernel.tiocsti_restrict = 1
697 This is already forced by the ``CONFIG_SECURITY_TIOCSTI_RESTRICT`` kernel
698 configuration option that we enable.
700 The following two sysctls help mitigating TOCTOU vulnerabilities by preventing
701 users from creating symbolic or hard links to files they do not own or have
702 read/write access to:
704 .. describe:: fs.protected_symlinks = 1
705 fs.protected_hardlinks = 1
707 In addition, the following other two sysctls impose restrictions on the
708 opening of FIFOs and regular files in order to make similar spoofing attacks
711 .. describe:: fs.protected_fifos = 2
712 fs.protected_regular = 2
714 We do not simply disable the BPF Just in Time compiler as CLIP OS plans on
717 .. describe:: kernel.unprivileged_bpf_disabled = 1
719 Prevent unprivileged users from using BPF.
721 .. describe:: net.core.bpf_jit_harden = 2
723 Trades off performance but helps mitigate JIT spraying.
725 .. describe:: kernel.deny_new_usb = 0
727 The management of USB devices is handled at a higher level by CLIP OS.
730 .. describe:: kernel.device_sidechannel_restrict = 1
732 Restrict device timing side channels. [linux-hardened]_
734 .. describe:: fs.suid_dumpable = 0
736 Do not create core dumps of setuid executables. Note that we already
737 disable all core dumps by setting ``CONFIG_COREDUMP=n``.
739 .. describe:: kernel.pid_max = 65536
741 Increase the space for PID values.
743 .. describe:: kernel.modules_disabled = 1
745 Disable module loading once systemd has loaded the ones required for the
746 running machine according to a profile (i.e., a predefined and
747 hardware-specific list of modules).
749 Pure network sysctls (``net.ipv4.*`` and ``net.ipv6.*``) will be detailed in a
753 Command line parameters
754 -----------------------
756 We pass the following command line parameters to the kernel:
758 .. describe:: extra_latent_entropy
760 This parameter provided by a linux-hardened patch (based on the PaX
761 implementation) enables a very simple form of latent entropy extracted
762 during system start-up and added to the entropy obtained with
763 ``GCC_PLUGIN_LATENT_ENTROPY``.
767 This force-enables KPTI even on CPUs claiming to be safe from Meltdown.
769 .. describe:: spectre_v2=on
771 Same reasoning as above but for the Spectre v2 vulnerability. Note that this
772 implies ``spectre_v2_user=on``, which enables the mitigation against user
773 space to user space task attacks (namely IBPB and STIBP when available and
776 .. describe:: spec_store_bypass_disable=seccomp
778 Same reasoning as above but for the Spectre v4 vulnerability. Note that this
779 mitigation requires updated microcode for Intel processors.
781 .. describe:: iommu=force
783 Even if we correctly enable the IOMMU in the kernel configuration, the
784 kernel can still decide for various reasons to not initialize it at boot.
785 Therefore, we force it with this parameter. Note that with some Intel
786 chipsets, you may need to add ``intel_iommu=igfx_off`` to allow your GPU to
787 access the physical memory directly without going through the DMA Remapping.
789 .. describe:: slub_debug=F
791 The ``F`` option adds many sanity checks to various slab operations. Other
792 interesting options that we considered but eventually chose to not use are:
794 * The ``P`` option, which enables poisoning on slab cache allocations,
795 disables the ``SLAB_SANITIZE`` and ``SLAB_SANITIZE_VERIFY`` features from
796 linux-hardened. As they respectively poison with zeroes on object freeing
797 and check the zeroing on object allocations, we prefer enabling them
798 instead of using ``slub_debug=P``.
799 * The ``Z`` option enables red zoning, i.e., it adds extra areas around
800 slab objects that detect when one is overwritten past its real size.
801 This can help detect overflows but we already rely on ``SLAB_CANARY``
802 provided by linux-hardened. A canary is much better than a simple red
803 zone as it is supposed to be random.
807 * ``slub_nomerge`` is not used as we already set
808 ``CONFIG_SLAB_MERGE_DEFAULT=n`` in the kernel configuration.
809 * ``page_poison`` is not needed by the page poisoning implementation provided
810 by linux-hardened patches.
811 * ``l1tf``: The built-in PTE Inversion mitigation is sufficient to mitigate
812 the L1TF vulnerability as long as CLIP OS is not used as an hypervisor with
813 untrusted guest VMs. If it were to be someday, ``l1tf=full,force`` should be
814 used to force-enable VMX unconditional cache flushes and force-disable SMT
815 (note that an Intel microcode update is not required for this mitigation to
816 work but improves performance by providing a way to invalidate caches with a
819 .. rubric:: Citations and origin of some items
822 This item is provided by the ``linux-hardened`` patches.
824 .. vim: set tw=79 ts=2 sts=2 sw=2 et: