User:Pietinger/Tutorials/Kernel Hardening with KSPP
No, KSPP does not mean Kerbal Space Program Project !
Tutorial: Kernel Hardening with KSPP
This tutorial shows an easy way to harden your kernel. Only our default sys-kernel/gentoo-sources will be used.
If you think you dont need it because you use a Hardened-Profile you are wrong. The Hardened-Profile has no hardened kernel; you must harden your kernel by yourself ! If you want to know the difference between Vanilla/normal Gentoo and Hardened Gentoo, take a look here: Hardened/Toolchain#Changes
Maybe this article will become obsolete when kernel version 6.7 is available, because then we will have this:
Also described here: https://www.phoronix.com/news/Linux-6.7-Hardening
Update: I said that it could become obsolete with kernel version 6.7. Since I have now installed 6.7.0, I immediately looked at the file /usr/src/linux-6.7.0-gentoo/kernel/configs/hardening.config and the file /usr/src/linux-6.7.0-gentoo/arch/x86/configs/hardening.config and realized that only the most primitive options are activated.
This means that the KSPP page is much more comprehensive and should still be our target.
Kees Cook wrote on Mastodon on November 6, 2025:
Today is also the 10 year anniversary of the Linux Kernel Self-Protection Project. I'm proud that we've gotten A LOT done in the last decade to harden Linux against security flaws.
Link to KSPP
In every case you need this: https://kspp.github.io/Recommended_Settings
Print the whole page or copy it into a text-file; you will need it later.
The following patch has not (yet) been included in the kernel, but contains more detailed explanations of some options (for reading only): https://lore.kernel.org/kernel-hardening/1536516257-30871-1-git-send-email-s.mesoraca16@gmail.com/
Linux Security Summit Talks
- In this video from the "Linux Security Summit 2021" Kees Cook (who also updates this KSPP Page) explains why it is so important to harden your kernel and also explains the progress made from Linux version 5.3 until 5.15: https://www.youtube.com/watch?v=-Binxid8t_8 I rate this as a must-see.
- Kees Cook & Gustavo A.R. Silva explain the "Progress On Bounds Checking in C and the Linux Kernel" (Linux Security Summit North America 2023): https://www.youtube.com/watch?v=V2kzptQG5_A
- Kees Cook talks about "Kernel Hardening: Ten Years Deep": https://www.youtube.com/watch?v=c_NxzSRG50g (Linux Security Summit North America 2025). I rate this as a must-see. Dont worry the presentation only lasts 30 minutes (the rest is question and answer with the audience). Have a look at the two slides at timestamp 14:58 and 22:22. I am adding a link because the PDF of the presentation can be found there: [[1]].
Transfer KSPP settings into your kernel
Of course you can / must set all these settings manually into your kernel. This you have to do if you dont use Gentoo-Sources or you use gentoo-sources-7.2 (because in version 7.2 of gentoo-sources the option "Kernel Self Protection Project" was removed).
With Gentoo-Sources until version 7.1 there is an easy way ... Maybe you have already seen this kernel setting:
Gentoo Linux --->
[ ] Kernel Self Protection Project
After enabling this option maybe you will see this (the second option only appears when you have enabled the first):
--- Kernel Self Protection Project
[*] Enable Kernel Self Protection Project Recommendations
[ ] X86_64 KSPP Settings
Maybe you dont have these two options. Why ?
If you read all recommended settings in KSPP Homepage you will see there are many kernel options which must be disabled. Disabling a kernel option with a Kconfig file is not possible. The only way to proof if something is disbled is a check in Kconfig with "... !options". ! means: NOT. Now look into /usr/src/linux/distro/Kconfig. You will see in the second half of this file a line like this:
/usr/src/linux/distro/Kconfig of Kernel Version 6.18depends on GENTOO_LINUX && !SLAB_MERGE_DEFAULT && !SLUB_TINY && !COMPAT_BRK && !PROC_KCORE && !COMPAT_VDSO && !KEXEC && !HIBERNATION && !LEGACY_PTYS && !X86_X32_ABI && !MODIFY_LDT_SYSCALL && GCC_PLUGINS && !IOMMU_DEFAULT_DMA_LAZY && !IOMMU_DEFAULT_PASSTHROUGH && IOMMU_DEFAULT_DMA_STRICT && SECURITY
If one of these options are enabled this line cause a hiding of this option. For example if you have enabled Hibernation you will not see the kernel option "Enable Kernel Self Protection Project Recommendations".
But I need Hibernation
If you now think that you can't use this because you absolutely need “hibernation”, then there is a little trick that you can use to get everything anyway:
1. Disable hibernation (and do everything mentionend in the next chapter)
2. Enable these two settings (and everything else you want to enable or disable)
3. Exit “make menuconfig” with save
4. Go back to “make menuconfig” and disable the two settings -> Yes, all settings through these two REMAIN.
5. Enable hibernation again
If you have any questions, please read the short chapter: User:Pietinger/Tutorials/Manual_kernel_configuration#Is_a_.22make_defconfig.22_required_before_starting.3F
Course of action
[2026-08-18] Temporary note (until the KSPP page is updated):
In kernel version 7.2, option CONFIG_RANDOM_KMALLOC_CACHES was renamed (and split) into CONFIG_KMALLOC_PARTITION_CACHES and CONFIG_KMALLOC_PARTITION_RANDOM.
Disable Options
If you have already configured the kernel according to one of these instructions, you should have already done everything necessary to make both options available.
Disable all other options described on the KSPP page (e.g. CONFIG_DEVMEM). Don't worry, some options are no longer available in 6.18: CONFIG_DEVKMEM was removed in 5.15, CONFIG_AMD_IOMMU_V2 in 6.7, ACPI_CUSTOM_METHOD in 6.9. CONFIG_GCC_PLUGIN_STACKLEAK was renamed to CONFIG_KSTACK_ERASE in 6.17.
These options are so old that I don't even remember when they were removed. Please note that the KSPP recommendations also apply to very old kernels, e.g., 5.10 or 5.15, and are therefore still listed: CONFIG_DEBUG_CREDENTIALS, CONFIG_PAGE_POISONING_NO_SANITY, CONFIG_PAGE_POISONING_ZERO and CONFIG_REFCOUNT_FULL
Do not disable IA32 if you have a Multilib-System. Do not disable Module-Support if you have kernel modules enabled with {M}. You can disable Module-Support only if you have a monolithic kernel.
If you do not have both options available, check this description to ensure that you have disabled all necessary options:
Minimum kernel configuration to get both KSPP options
... for a X86_64 system. You must enable "expert users" to be able to reach all necessary options. Now you have to disable and enable all these:
Kernel 6.6
General setup --->
[*] Configure standard kernel features (expert users) --->
Kexec and crash features --->
[ ] Enable kexec system call
[ ] Enable kexec file based system call
[ ] kernel crash dump
Processor type and features --->
[ ] Enable vsyscall emulation
[ ] /dev/cpu/*/msr - Model-specific register support
[ ] Enable the LDT (local descriptor table)
Power management and ACPI options --->
[ ] Hibernation (aka 'suspend to disk')
General architecture-dependent options --->
[*] GCC plugins --->
Memory Management options --->
[ ] Disable heap randomization
Device Drivers --->
Character devices --->
[ ] Legacy (BSD) PTY support
[*] IOMMU Hardware Support --->
IOMMU default domain type (Translated - Strict) --->
File systems --->
Pseudo filesystems --->
[ ] /proc/kcore support
Security options --->
[*] Enable different security models
Kernel hardening options --->
Randomize layout of sensitive kernel structures (Limit randomization of structure layout to cache-lines) --->
Kernel 6.12
Do all settings from 6.6. As soon as you disable "Enable kexec system call" the option "kernel crash dumps" will disappear:
General setup --->
Kexec and crash features --->
[ ] Enable kexec system call
[ ] Enable kexec file based system call
Kernel 6.17.8
Do all settings from 6.12, make sure both options in SLAB are disabled and change the Randomize layout to "Fully randomize":
Memory Management options --->
SLAB allocator options --->
[ ] Configure for minimal memory footprint
[ ] Allow slab caches to be merged
Security options --->
Kernel hardening options --->
Randomize layout of sensitive kernel structures (Fully randomize structure layout) --->
Enable both Gentoo Options
--- Kernel Self Protection Project
[*] Enable Kernel Self Protection Project Recommendations
[*] X86_64 KSPP Settings
Additional options on the KSPP page
... which are not configured by our Gentoo settings. A diff between KSPP version 2025-11-06 and our Gentoo settings for kernel version 6.18 will show these missing settings:
1) # Do not allow direct physical memory access (but if you must have it, at least enable STRICT mode...) # CONFIG_DEVMEM is not set CONFIG_STRICT_DEVMEM=y CONFIG_IO_STRICT_DEVMEM=y 2) # Do not allow manipulation of read-only memory through /proc/$pid/mem. # See also "proc_mem.force_override" sysctl below. CONFIG_PROC_MEM_NO_FORCE=y 3) CONFIG_LIST_HARDENED=y 4) # Make sure line disciplines can't be autoloaded (since v5.1). # CONFIG_LDISC_AUTOLOAD is not set 5) # Enable "lockdown" LSM for bright line between the root user and kernel memory. CONFIG_SECURITY_LOCKDOWN_LSM=y CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y 6) # Initialize all stack variables on function entry. (Clang and GCC 12+ builds only. For earlier GCC, see CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y below) CONFIG_INIT_STACK_ALL_ZERO=y 7) # Enable trapping bounds checking of array indexes (since v5.11). All the other UBSAN checks should be disabled. CONFIG_UBSAN=y CONFIG_UBSAN_TRAP=y CONFIG_UBSAN_BOUNDS=y CONFIG_UBSAN_SANITIZE_ALL=y # CONFIG_UBSAN_SHIFT is not set # CONFIG_UBSAN_DIV_ZERO is not set # CONFIG_UBSAN_UNREACHABLE is not set # CONFIG_UBSAN_SIGNED_WRAP is not set # CONFIG_UBSAN_BOOL is not set # CONFIG_UBSAN_ENUM is not set # CONFIG_UBSAN_ALIGNMENT is not set 8) # Do not ignore compile-time warnings (since v5.15) CONFIG_WERROR=y 9) # Disable DMA between EFI hand-off and the kernel's IOMMU setup. CONFIG_EFI_DISABLE_PCI_DMA=y 10) # Enable feeding RNG entropy from TPM, if available. CONFIG_HW_RANDOM_TPM=y 11) # Get as much entropy as possible from external sources. The Chacha mixer isn't vulnerable to injected entropy, so even # malicious sources should not cause problems. CONFIG_RANDOM_TRUST_BOOTLOADER=y CONFIG_RANDOM_TRUST_CPU=y 12) # Wipe RAM at reboot via EFI. CONFIG_RESET_ATTACK_MITIGATION=y 13) # This needs userspace support, and will break "regular" distros. See: https://github.com/tych0/huldufolk CONFIG_STATIC_USERMODEHELPER=y 14) # Easily confused by misconfigured userspace, keep off. # CONFIG_BINFMT_MISC is not set 15) # Block TTY stuffing attacks (this will break screen readers, see "dev.tty.legacy_tiocsti" sysctl below). # CONFIG_LEGACY_TIOCSTI is not set 16) # Reboot devices immediately if kernel experiences an Oops. [...] CONFIG_PANIC_TIMEOUT=-1 17) # Limit sysrq to sync,unmount,reboot. For more details see the sysrq bit field table: # https://docs.kernel.org/admin-guide/sysrq.html CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=176 18) # Keep root from altering kernel memory via loadable modules. # CONFIG_MODULES is not set # But if CONFIG_MODULE=y is needed, at least they must be signed with a per-build key. CONFIG_DEBUG_SET_MODULE_RONX=y (prior to v4.11) CONFIG_STRICT_MODULE_RWX=y (since v4.11) CONFIG_MODULE_SIG=y CONFIG_MODULE_SIG_FORCE=y CONFIG_MODULE_SIG_ALL=y CONFIG_MODULE_SIG_SHA512=y CONFIG_MODULE_SIG_HASH="sha512" CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
My comments
1. Yes, I suggest also to disable CONFIG_DEVMEM completely.
2. With kernel version 6.11.3 we have this new option. Do not change this if you want to continue using the GDB. An explanation can be found here: [[2]]
Security options --->
Allow /proc/pid/mem access override (Never) --->
3. Don't worry, this is enabled automatically by CONFIG_BUG_ON_DATA_CORRUPTION
4. This is very senseful and we have done it already.
5. See the big warning !
6. Enable it here:
Security options --->
Kernel hardening options --->
Memory initialization --->
Initialize kernel stack variables at function entry (zero-init everything (strongest and safest)) --->
7. Already enabled with our Gentoo-KSPP settings. Just check it.
8. This could make some problems when doing cross compile (I dont do and therefore I have enabled it).
9. See the big warning !
10. Only senseful if you have such a hardware module (I dont have; so its disabled).
11. I don't need it - your decision.
12. See the big warning !
13. Enable it and make sure that the PATH is empty. But test it if everything still works afterwards, because I got a report that iptables does not work properly anymore if it has to load netfilter modules (not verified because I have all netfilter modules statically configured in the kernel and therefore have no problem with iptables AND this option).
14. This is very senseful and we have done it already.
15. Read the <Help> and test it ... ;-)
16. I suggest to use CONFIG_PANIC_TIMEOUT=0 to see a kernel panic. You can use also CONFIG_PANIC_TIMEOUT=10 to have 10 seconds to see it (Read the <Help>)
17. I dont need this because I have disabled CONFIG_MAGIC_SYSRQ completly. If you use it then it is senseful to set this value.
18. I have disabled the module support and have a monolithic kernel ... after I found out which modules I need for my firewall ;-) If you need module support (e.g. for nvidia) sign your kernel modules.
Since 2023-10-20 we have new recommendations in KSPP. One of them is enabling LOCKDOWN. Do this only if you have signed your Kernel modules (see here: Signed_kernel_module_support ), OR you have a monolithic kernel (see more here: Kernel_Modules#Going_completely_.22module-less.22 ) !
If you boot a stub-kernel directly from UEFI, these settings could harm your boot sequence (BIOS hangs): CONFIG_EFI_DISABLE_PCI_DMA and CONFIG_RESET_ATTACK_MITIGATION. Best is to try only one of them and (if ok) then enable the second option.
Additional options on the KSPP page x86_64
x86_64 1) # Remove additional (32-bit) attack surface, unless you really need them. # CONFIG_COMPAT is not set # CONFIG_IA32_EMULATION is not set # CONFIG_X86_X32 is not set # CONFIG_X86_X32_ABI is not set 2) # Disallow allocating the first 64k of memory. CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 3) # Straight-Line-Speculation CONFIG_MITIGATION_SLS=y
My comments x86_64
1. You can do this only if you have a No-Multilib system. See also: User:Pietinger/Tutorials/Manual_Configuring_Kernel_Version_6.18#Binary_Emulations
2. This is very senseful and we have done it already.
3. If security is more important than performance enable it (I have it enabled) - All mitigitations cost some performance; dont use it for a gaming system:
[*] Mitigations for speculative execution vulnerabilities --->
[*] Mitigate Straight-Line-Speculation
Kernel Commandline Parameter
KSPP also provides you with some kernel parameters, but some are already unnecessary due to the settings in the kernel itself. Here is an overview:
| Commandline parameter | Kernel option |
|---|---|
| hardened_usercopy=1 | CONFIG_HARDENED_USERCOPY_DEFAULT_ON=y |
| init_on_alloc=1 | CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y |
| init_on_free=1 | CONFIG_INIT_ON_FREE_DEFAULT_ON=y |
| randomize_kstack_offset=on | CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y |
| slab_nomerge | # CONFIG_SLAB_MERGE_DEFAULT is not set |
| iommu.passthrough=0 iommu.strict=1 | CONFIG_IOMMU_DEFAULT_DMA_STRICT=y # CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set |
| page_table_check=on | CONFIG_PAGE_TABLE_CHECK_ENFORCED=y |
| vsyscall=none | CONFIG_LEGACY_VSYSCALL_NONE=y |
| vdso32=0 | # CONFIG_COMPAT_VDSO is not set |
I do not want to activate some parameters (e.g. nosmt) because, in my opinion, they are only necessary for systems that run virtual machines. But it is your decision.
The following remain, which I have stored in the kernel itself for safety reasons (so that they are never lost):
Processor type and features --->
[*] Built-in kernel command line
(page_alloc.shuffle=1 pti=on slub_debug=ZF)
When using a Kernel version 6.17 or higher add an additional parameter:
Processor type and features --->
[*] Built-in kernel command line
(page_alloc.shuffle=1 pti=on slub_debug=ZF hash_pointers=always)
Options in Sysctl
Don't forget some settings in SYSCTL. You can copy it from KSPP directly in (just add them at the end). Here, you should check whether there are any settings you should NOT apply, as they might cause problems for you; for example, `kernel.modules_disabled = 1`.
root #nano -w /etc/sysctl.confIf you have problems when emerging some packages (e.g. dev-lang/go) because of this:
/etc/sysctl.confkernel.yama.ptrace_scope = 3
Then set it to 2 (or even 1). Please see more in: /usr/src/linux/Documentation/admin-guide/LSM/Yama.rst
A note on this parameter: "user.max_user_namespaces = 0". Attempts to create a namespace fail with the error ENOSPC, and this is the kernel's correct error message (even if it is confusing) because, due to the zeroing operation, there is "no more space" available.
root #unshare -U /bin/bashunshare: unshare failed: No space left on device
Slow System start ?
If you boot the first time with these new settings you will notice that your kernel needs longer to start. Before it took 1.2 seconds (until "Run /sbin/init as init process") and now kernel needs 2.5 seconds. If you think this is crazy; these settings have halved my CPU performance ... then don't worry ... and look carefully into your dmesg output and examine the timestamps. You will find something like this:
root #dmesg[...] [ 0.030070] mem auto-init: stack:all(zero), heap alloc:on, heap free:on [ 0.030071] mem auto-init: clearing system memory may take some time... [ 0.030076] software IO TLB: area num 8. [ 1.358628] Memory: 16087256K/16653428K available (14343K kernel code, 1960K rwdata, 2456K rodata, 1564K init, 2888K bss, 565912K reserved, 0K cma-reserved) [...]
(As you can see I have 16 GB RAM; machine is an Intel i7; but it doesn't matter how many cores your CPU has).
Yes, for security reasons your kernel will clear now your whole memory (with ONE Core of your CPU). If you have a 64 GB RAM machine you can expect it took aprox. 5 seconds.
More Hardening Options
I deactivate the Magic SysRq key completely:
Kernel hacking --->
Generic Kernel Debugging Instruments --->
[ ] Magic SysRq key
When Google disables IO_URING then I do the same ;-) see more here: [[3]] I have also deactivated the associated use flag globally in my make.conf: USE="... -io-uring ..."
[2025-04-24] There is also a report from Bruce Schneier about a new rootkit using io-uring: https://www.schneier.com/blog/archives/2025/04/new-linux-rootkit.html
General setup --->
[*] Configure standard kernel features (expert users) --->
[ ] Enable IO uring support
I also deactivate two obsolete system calls. With kernel version 6.15 the option "Sysfs syscall support" has been moved from this submenu directly to "General setup" and is now disabled by default.
General setup --->
[*] Configure standard kernel features (expert users) --->
[ ] sgetmask/ssetmask syscalls support
[ ] Sysfs syscall support
An even more radical method than "kernel.kptr_restrict = 2" is to remove it entirely (Note: Kernel error messages will no longer include function names, which makes troubleshooting more difficult):
General setup --->
[*] Configure standard kernel features (expert users) --->
[ ] Load all symbols for debugging/ksymoops
This is an old recommendation and not that critical. If it hasn't caused any problems with your video driver, you can activate it without hesitation:
Device Drivers --->
Generic Driver Options --->
[*] Use nosuid,noexec mount options on devtmpfs
[2025-06-06] Even though it doesn't affect Gentoo at the moment, I've always been skeptical about COREDUMP and have disabled it for a long time (also because my kernel runs rock solid and I don't need it). I share this opinion from Jason Soroko: "Crash handlers remain a hidden weak point in Linux hygiene,": [[4]]. I don't know if systemd needs this (I have an OpenRC system).
Executable file formats --->
[ ] Enable core dump support
Check it with kernel-hardening-checker
This program was written by Alexander Popov, who also created the “Linux Kernel Defense Map”. If you are interested you could have a look at his slides for his talk at H2HC 2024-12: https://a13xp0p0v.github.io/img/Alexander_Popov-H2HC-2024.pdf
Watch at least the first 16 minutes of this recent (May 27, 2026) talk by him: https://www.youtube.com/watch?v=zXVqGaJY6iM If you ever want to see how a hardened kernel fends off an attack, the 6 seconds from the timestamp 27:43 to 27:49 are a real treat to watch ("Yeah, baby").
At the moment it is not stable, so you must add this package to your /etc/portage/package.accept_keywords
root #emerge -pv kernel-hardening-checkerStart it with:
root #kernel-hardening-checker -c /usr/src/linux/.configDo not worry if some points are displayed as "Fail". You can only have AMD or Intel MCE ... or IOMMU ... ;-) See my result:
[+] Kconfig file to check: /usr/src/linux/.config
[+] Detected architecture: X86_64
[+] Detected kernel version: 6.1
[+] Detected compiler: GCC 130201
option name | type |desired val | decision | reason | check result
CONFIG_BUG |kconfig| y |defconfig | self_protection | OK
CONFIG_SLUB_DEBUG |kconfig| y |defconfig | self_protection | OK
CONFIG_THREAD_INFO_IN_TASK |kconfig| y |defconfig | self_protection | OK
CONFIG_GCC_PLUGINS |kconfig| y |defconfig | self_protection | OK
CONFIG_IOMMU_SUPPORT |kconfig| y |defconfig | self_protection | OK
CONFIG_STACKPROTECTOR |kconfig| y |defconfig | self_protection | OK
CONFIG_STACKPROTECTOR_STRONG |kconfig| y |defconfig | self_protection | OK
CONFIG_STRICT_KERNEL_RWX |kconfig| y |defconfig | self_protection | OK
CONFIG_STRICT_MODULE_RWX |kconfig| y |defconfig | self_protection | OK: CONFIG_MODULES is "is not set"
CONFIG_REFCOUNT_FULL |kconfig| y |defconfig | self_protection | OK: version >= 5.5
CONFIG_RANDOMIZE_BASE |kconfig| y |defconfig | self_protection | OK
CONFIG_VMAP_STACK |kconfig| y |defconfig | self_protection | OK
CONFIG_DEBUG_WX |kconfig| y |defconfig | self_protection | OK
CONFIG_WERROR |kconfig| y |defconfig | self_protection | OK
CONFIG_X86_MCE |kconfig| y |defconfig | self_protection | OK
CONFIG_X86_MCE_INTEL |kconfig| y |defconfig | self_protection | OK
CONFIG_X86_MCE_AMD |kconfig| y |defconfig | self_protection | FAIL: is not found
CONFIG_MICROCODE |kconfig| y |defconfig | self_protection | OK
CONFIG_RETPOLINE |kconfig| y |defconfig | self_protection | OK
CONFIG_SYN_COOKIES |kconfig| y |defconfig | self_protection | OK
CONFIG_X86_SMAP |kconfig| y |defconfig | self_protection | OK: version >= 5.19
CONFIG_X86_UMIP |kconfig| y |defconfig | self_protection | OK
CONFIG_PAGE_TABLE_ISOLATION |kconfig| y |defconfig | self_protection | OK
CONFIG_RANDOMIZE_MEMORY |kconfig| y |defconfig | self_protection | OK
CONFIG_INTEL_IOMMU |kconfig| y |defconfig | self_protection | OK
CONFIG_AMD_IOMMU |kconfig| y |defconfig | self_protection | FAIL: "is not set"
CONFIG_BUG_ON_DATA_CORRUPTION |kconfig| y | kspp | self_protection | OK
[...]
Please do not worry if some options are displayed as "fail"; we cannot configure everything as is the case with other systems (e.g. we must have KCMP activated). Others are obsolete, such as CONFIG_CHECKPOINT_RESTORE, as we now have the "CAP_CHECKPOINT_RESTORE" capability since Linux 5.9 (see also "man capabilities(7)"). You can also set/disable other options as a test (e.g. CONFIG_DEVPORT) if you do not have any applications or sensors that require this.
Interestingly, grsec and ClipOS [[5]] do the same as I do with IO_URING ... :-D
Supplement: Because some users asked what else could be configured based on the kernel-hardening-checker output, I'll add my opinion here:
What we need at Gentoo - so don't think about it:
- CONFIG_FB
- CONFIG_VT
- CONFIG_KCMP
- CONFIG_RSEQ
- CONFIG_USER_NS (But don't worry, because we've set user.max_user_namespaces = 0 as recommended by KSPP. See in: "Options in Sysctl")
- CONFIG_BLK_DEV_WRITE_MOUNTED
This could interfere with your boot process (just test it):
- CONFIG_EFI_DISABLE_PCI_DMA
- CONFIG_RESET_ATTACK_MITIGATION
Only if you use CLANG instead GCC:
- CONFIG_CFI_CLANG
- CONFIG_CFI_PERMISSIVE
Only useful if you have a hardware TPM:
- CONFIG_HW_RANDOM_TPM
Be very careful here - Check if everything runs after this:
- CONFIG_X86_IOPL_IOPERM
Good candidates:
- CONFIG_IO_URING
- CONFIG_AIO
- CONFIG_MAGIC_SYSRQ
- CONFIG_BPF_SYSCALL
- CONFIG_DEVPORT
- CONFIG_COREDUMP
You must decide:
- CONFIG_PROC_PAGE_MONITOR
- CONFIG_CACHESTAT_SYSCALL
Check it with spectre-meltdown-checker
At the moment we only have version 0.46 and therefore I suggest to get it directly from GITHUB to get version 0.46+: [[6]]
In the end, everything should be green (example of my Intel machine):
# ./spectre-meltdown-checker.sh Spectre and Meltdown mitigation detection tool v0.46+ [... detailed output about the system ...] > SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OK CVE-2018-12207:OK CVE-2020-0543:OK CVE-2023-20593:OK CVE-2022-40982:OK CVE-2023-20569:OK CVE-2023-23583:OK
What is Kerbal Space Program?
It is a very famous video game, or more precisely, a space flight simulation: https://en.wikipedia.org/wiki/Kerbal_Space_Program
It has even been mentioned in XKCD: https://xkcd.com/2204/
However, this is less glorious and not so well known: https://xgqt.gitlab.io/spywarewatchdog/articles/ksp.html
This is my third try for creating a wiki article. Maybe some formatting is wrong. Because it is a tutorial and not a reference guide I ignored the standard of not writing in first or second person. Yes, my english is very poor.