Merge remote-tracking branch 'ArrayBolt3/arraybolt3/trixie'

2026-01-04 04:15:33 -05:00 · 2025-12-02 06:04:07 -05:00 · 2025-12-02 06:04:07 -05:00 · 6f9732be98
commit 6f9732be98
parent 2089b3a9b8 b3eb739fe2
5 changed files with 234 additions and 46 deletions
--- a/README.md
+++ b/README.md
@ -50,16 +50,23 @@ configuration file and significant hardening is applied to a myriad of component
  and thwart certain kernel exploitation attempts) and kernel warnings in the `WARN()` path.

 - Force immediate system reboot on the occurrence of a single kernel panic, reducing the
-  risk and impact of denial of service attacks and both cold and warm boot attacks.
+  risk and impact of denial-of-service attacks and both cold and warm boot attacks.

- Optional - Force immediate kernel panic on OOM. This is to avoid security features such as the screen
-  locker, kloak, emerg-shutdown from being arbitrarily terminated when the system starts
-  running out of memory.
+- Optional - Force immediate kernel panic on OOM (out of memory) which with the above setting
+  will force an immediate system reboot as opposed to placing any reliance on the oom_killer
+  to avoid arbitrarily terminating security features based on their OOM score. Note this
+  creates the risk of userspace-based denial-of-service attacks that maliciously fill memory.
+
+- Optional - Force immediate kernel panics upon receiving NMIs (Non-Maskable Interrupts)
+  triggered by serious hardware-level I/O issues, uncorrectable memory and hardware errors,
+  and undefined or unknown sources in order to prevent data corruption.

 - Disable the use of legacy TIOCSTI operations which can be used to inject keypresses.

 - Disable asynchronous I/O as `io_uring` has been the source of numerous kernel exploits.

+- Disable 32-bit vDSO mappings as they are a legacy compatibility feature.
+
 #### User space

 - Disable the usage of `ptrace()` by all processes as it enables programs to inspect
@ -132,6 +139,9 @@ configuration file and significant hardening is applied to a myriad of component

 - Disable TCP timestamps as they can allow detecting the system time.

+- Disable reuse of `TIME_WAIT` sockets for new outgoing connections as the above
+  setting disables TCP timestamps.
+
 - Optional - Log packets with impossible source or destination addresses to
  enable further inspection and analysis.

@ -156,6 +166,8 @@ CPU mitigations:

 - Spectre Side Channels (BTI and BHI)

+- Meltdown
+
 - Speculative Store Bypass (SSB)

 - L1 Terminal Fault (L1TF)
@ -206,8 +218,8 @@ Kernel space:
 - Enable the kernel page allocator to randomize free lists to limit some data
  exfiltration and ROP attacks, especially during the early boot process.

- Enable kernel page table isolation to increase KASLR effectiveness and also
-  mitigate the Meltdown CPU vulnerability.
+- Enable kernel page table isolation on x86_64 and ARM64 CPUs to increase
+  KASLR effectiveness and also mitigate the Meltdown CPU vulnerability.

 - Enable randomization of the kernel stack offset on syscall entries to harden
  against memory corruption attacks.
@ -218,10 +230,11 @@ Kernel space:
 - Restrict access to debugfs by not registering the file system since it can
  contain sensitive information.

- Force kernel panics on "oopses" to potentially indicate and thwart certain
-  kernel exploitation attempts.
+- Force the kernel to immediately panic on both "oopses" (which can potentially indicate
+  and thwart certain kernel exploitation attempts) and kernel warnings in the `WARN()` path.

- Optional - Modify the machine check exception handler.
+- Force immediate system reboot on the occurrence of a single kernel panic, reducing the
+  risk and impact of denial-of-service attacks and both cold and warm boot attacks.

 - Prevent sensitive kernel information leaks in the console during boot.

@ -238,6 +251,15 @@ Kernel space:
 - Disable the EFI persistent storage feature which prevents the kernel from writing crash logs
  and other persistent data to either the UEFI variable storage or ACPI ERST backends.

+- Optional - On compatible AMD CPUs enable Secure Memory Encryption (SME) to protect against
+  cold boot attacks and Secure Encrypted Virtualization (SEV) for further guest memory isolation.
+
+- Prevent runaway privileged processes from writing to block devices that are mounted by
+  filesystems to protect against filesystem corruption and kernel crashes.
+
+- Restrict processes from modifying their own memory mappings unless actively done via
+  `ptrace()` in order to limit self-modification which can trigger exploits.
+
 Direct memory access:

 - Enable strict IOMMU translation to protect against some DMA attacks via the use
@ -248,12 +270,21 @@ Direct memory access:

 Entropy:

- Do not credit the CPU or bootloader as entropy sources at boot in order to
-  maximize the absolute quantity of entropy in the combined pool.
+- Do not credit the CPU seeds as an entropy source at boot in order to maximize the
+  absolute quantity of entropy in the combined pool. This is desirable for all
+  cryptographic operations, to avoid reliance on proprietary RDRAND and RDSEED CPU
+  instructions for random number generation that have long history of being defective.
+
+- Do not credit the bootloader seeds as an entropy sources at boot to maximize the
+  absolute quantity of entropy in the combined pool. This is desirable for all
+  cryptographic operations as seeds passed by the bootloader could be tampered.

 - Obtain more entropy at boot from RAM as the runtime memory allocator is
  being initialized.

+- Obtain more entropy at boot from RAM as the runtime memory allocator is being
+  initialized to maximize the absolute quantity of entropy in the combined pool.
+
 Networking:

 - Optional - Disable the entire IPv6 stack to reduce attack surface.
@ -295,6 +326,14 @@ feasible due to compatibility issues with Firefox.
 * [security-misc pull request #249](https://github.com/Kicksecure/security-misc/pull/249)
 * [security-misc issue #267](https://github.com/Kicksecure/security-misc/issues/267)

+3. Kernel boot parameter `hash_pointers=always`
+
+Force all exposed pointers to be hashed and must be used in combination with the already enabled
+`slab_debug=FZ` kernel boot parameter. Currently is not possible as requires Linux kernel >= 6.17.
+
+* [security-misc issue #253](https://github.com/Kicksecure/security-misc/issues/253)
+* [security-misc pull request #325](https://github.com/Kicksecure/security-misc/pull/325)
+
 ### Kernel Modules

 #### Kernel Module Signature Verification
--- a/etc/default/grub.d/40_cpu_mitigations.cfg#security-misc-shared
+++ b/etc/default/grub.d/40_cpu_mitigations.cfg#security-misc-shared
@ -71,10 +71,24 @@ GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX nosmt=force"
 GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX spectre_v2=on"
 GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX spectre_bhi=on"

+## Meltdown:
+## Mitigate Spectre Variant 3 using kernel page table isolation (PTI).
+## Force enable PTI of user and kernel address spaces on all cores.
+## Mitigations for X86_64 CPUs are done in /etc/default/grub.d/40_kernel_hardening.cfg using "pti=on".
+## Currently affects ARM64 CPUs.
+##
+## https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
+## https://en.wikipedia.org/wiki/Kernel_page-table_isolation
+##
+## KSPP=yes
+## KSPP sets CONFIG_UNMAP_KERNEL_AT_EL0=y.
+##
+GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX kpti=1"
+
 ## Speculative Store Bypass (SSB):
 ## Mitigate Spectre Variant 4 by disabling speculative store bypass system-wide.
 ## Unconditionally enable the mitigation for both kernel and userspace.
-## Currently affects both AMD and Intel CPUs.
+## Currently affects AMD, ARM64, and Intel CPUs.
 ##
 ## https://en.wikipedia.org/wiki/Speculative_Store_Bypass
 ## https://www.suse.com/support/kb/doc/?id=000019189
--- a/etc/default/grub.d/40_kernel_hardening.cfg#security-misc-shared
+++ b/etc/default/grub.d/40_kernel_hardening.cfg#security-misc-shared
@ -38,13 +38,17 @@ kver="$(dpkg-query --show --showformat='${Version}' "$kpkg")" 2>/dev/null || tru
 ##
 GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX slab_nomerge"

-## Enable sanity checks and red zoning of slabs via debugging options to detect corruption.
+## Enable sanity checks and red zoning of slabs via debugging options to detect memory corruption.
+## Sanity checks force additional verification steps on every memory allocation and free operation.
+## Red zoning adds extra metadata to each object to detect writes beyond the object's boundaries.
 ## As a by product of debugging, this will implicitly disabling kernel pointer hashing unless manually re-enabled.
 ## Enabling this (for now) will therefore leak exact and all kernel memory addresses to root.
-## Has the potential to cause a noticeable performance decrease.
+## Introduces a noticeable performance overhead during all memory allocation and deallocation operations.
 ##
 ## https://www.kernel.org/doc/html/latest/mm/slub.html
+## https://www.kernel.org/doc/Documentation/vm/slub.txt
 ## https://lore.kernel.org/all/20210601182202.3011020-5-swboyd@chromium.org/T/#u
+## https://blogs.oracle.com/linux/post/linux-slub-allocator-internals-and-debugging-2
 ## https://gitlab.tails.boum.org/tails/tails/-/issues/19613
 ## https://github.com/Kicksecure/security-misc/issues/253
 ##
@ -83,8 +87,10 @@ GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX init_on_free=1"
 GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX page_alloc.shuffle=1"

 ## Enable kernel page table isolation to harden against kernel ASLR (KASLR) bypasses.
-## Mitigates the Meltdown CPU vulnerability.
+## Mitigates the Meltdown (Spectre Variant 3) CPU vulnerability.
+## Mitigations for ARM64 CPUs are done in /etc/default/grub.d/40_cpu_mitigations.cfg using "kpti=1".
 ##
+## https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
 ## https://en.wikipedia.org/wiki/Kernel_page-table_isolation
 ##
 ## KSPP=yes
@ -122,33 +128,40 @@ GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX vsyscall=none"
 ##
 GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX debugfs=off"

-## Force the kernel to immediately panic on "oopses".
+## Force the kernel to immediately panic on "oopses" and kernel warnings in the WARN() path.
 ## Panics may be due to false-positives such as bad drivers.
+## Both allowed limits are set to one so that panics occur on the single first instance of either scenario.
 ## Oopses are serious but non-fatal errors.
 ## Certain "oopses" can sometimes indicate and thwart potential kernel exploitation attempts.
-## Note that by forcing kernel panics on oopses, this exposes the system to targeted denial of service attacks.
+## Warnings are messages generated by the kernel to indicate unexpected conditions or errors.
+## By default, code execution continues regardless of warnings emitted by macros like WARN() and WARN_ON().
+## Note that by forcing kernel panics on oopses and warnings, this exposes the system to targeted denial of service attacks.
 ##
 ## https://en.wikipedia.org/wiki/Kernel_panic#Linux
 ## https://en.wikipedia.org/wiki/Linux_kernel_oops
+## https://lwn.net/Articles/876209/
+## https://git.sr.ht/~gregkh/presentation-security/tree/3fdaf81a2f8b2c8d64cdb2f529cc714624868aa8/item/security-stuff.pdf
 ## https://forums.whonix.org/t/set-oops-panic-kernel-parameter-or-kernel-panic-on-oops-1-sysctl-for-better-security/7713
 ##
 ## KSPP=yes
-## KSPP sets CONFIG_PANIC_ON_OOPS=y and CONFIG_PANIC_TIMEOUT=-1.
+## KSPP sets CONFIG_PANIC_ON_OOPS=y.
 ##
 ## See /usr/libexec/security-misc/panic-on-oops for implementation.
 ##
 #GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX oops=panic"
+#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX panic_on_warn=1"

-## Modify machine check exception handler.
-## Can decide whether the system should panic or not based on the occurrence of an exception.
+## Force immediate system reboots on the occurrence of a single kernel panic.
+## Increases resilience and limits impact of denial of service attacks as system automatically restarts.
+## Ensures the system does not hang forever if a panic occurs, reducing susceptibility to both cold and warm boot attacks.
+## Immediate rebooting also prevents persistent information disclosure on panic details that were dumped to screen.
 ##
-## https://www.kernel.org/doc/html/latest/arch/x86/x86_64/machinecheck.html
-## https://www.kernel.org/doc/html/latest/arch/x86/x86_64/boot-options.html#machine-check
-## https://forums.whonix.org/t/kernel-hardening/7296/494
+## KSPP=yes
+## KSPP sets CONFIG_PANIC_TIMEOUT=-1.
 ##
-## The default kernel setting will be utilized until provided sufficient evidence to modify.
+## See /usr/libexec/security-misc/panic-on-oops for implementation.
 ##
-#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX mce=0"
+#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX panic=-1"

 ## Prevent sensitive kernel information leaks in the console during boot.
 ## Must be used in combination with the kernel.printk sysctl.
@ -186,6 +199,8 @@ GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX kfence.sample_interval=100"
 ## KSPP=yes
 ## KSPP sets the kernel parameter and does not set CONFIG_COMPAT_VDSO.
 ##
+## See /usr/lib/sysctl.d/990-security-misc.conf for another additional implementation.
+##
 GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX vdso32=0"

 ## Switch (back) to using kCFI as the default Control Flow Integrity (CFI) implementation.
@ -237,6 +252,54 @@ GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX ia32_emulation=0"
 GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX efi_pstore.pstore_disable=1"
 GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX erst_disable"

+## Enable AMD Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV).
+## SME encrypts memory with a single key at the kernel level to protect against cold boot attacks.
+## SEV extends SME to VMs by encrypting the memory of each with a unique key for guest isolation.
+## This is hardware-based encryption managed by the proprietary and closed-source AMD Platform Security Processor (PSP).
+## Both require a compatible AMD CPU and support for SME to first be enabled in the BIOS/UEFI.
+## Likely unavailable in consumer-grade AMD CPUs where Transparent SME (TSME) can be enabled in the BIOS/UEFI to achieve SME.
+## Note the corresponding Intel Total Memory Encryption (TME) can also be enabled via the BIOS/UEFI.
+## May cause boot failure on certain hardware with incompatible DMA masks.
+##
+## https://www.kernel.org/doc/html/next/x86/amd-memory-encryption.html
+## https://www.kernel.org/doc/html/latest/virt/kvm/x86/amd-memory-encryption.html
+## https://docs.amd.com/v/u/en-US/memory-encryption-white-paper
+## https://docs.amd.com/v/u/en-US/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more
+## https://en.wikichip.org/wiki/x86/sme
+## https://lore.kernel.org/lkml/YWvy9bSRaC+m1sV+@zn.tnic/T/#m01bcb37040b6b0d119d385d9a34b9c7ac4ce5f84
+## https://mricher.fr/post/amd-memory-encryption/
+## https://www.kicksecure.com/wiki/Dev/confidential_computing#AMD
+## https://forums.whonix.org/t/enable-secure-memory-encryption-sme-kernel-parameter-mem-encrypt-by-default/10393
+##
+#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX mem_encrypt=on"
+#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX kvm_amd.sev=1"
+
+## Prevent processes from writing to block devices that are mounted by filesystems.
+## Enhances system stability and security by protecting against runaway privileged processes.
+## Allowing processes to write to the buffer cache can cause filesystem corruption and kernel crashes.
+## Does not prevent data modifications using direct SCSI commands or lower-level storage stack access.
+## May lead to breakages in certain limited scenarios.
+##
+## https://github.com/torvalds/linux/commit/ed5cc702d311c14b653323d76062b0294effa66e
+## https://lore.kernel.org/lkml/20240105-vfs-super-4092d802972c@brauner/
+## https://github.com/a13xp0p0v/kernel-hardening-checker/issues/186
+##
+GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX bdev_allow_write_mounted=0"
+
+## Restrict processes from modifying their own memory mappings.
+## Prevents the use of /proc/PID/mem to write to protected pages via the kernel's
+## mem_rw() FOLL_FORCE flag. This makes it harder to trick applications into
+## overwriting their own memory.
+##
+## https://lore.kernel.org/lkml/20240712-vfs-procfs-ce7e6c7cf26b@brauner/
+## https://lwn.net/Articles/983169/
+## https://github.com/a13xp0p0v/kernel-hardening-checker/pull/201
+## https://github.com/Kicksecure/security-misc/issues/330
+##
+## Using "proc_mem.force_override=never" provides superior protection by never allowing overrides.
+##
+GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX proc_mem.force_override=ptrace"
+
 ## 2. Direct Memory Access:
 ##
 ## https://madaidans-insecurities.github.io/guides/linux-hardening.html#dma-attacks
@ -282,32 +345,48 @@ GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX efi=disable_early_pci_dma"
 ##
 ## https://madaidans-insecurities.github.io/guides/linux-hardening.html#rdrand

-## Do not credit the CPU or bootloader seeds as entropy sources at boot.
-## The RDRAND CPU (RNG) instructions are proprietary and closed-source.
-## Numerous implementations of RDRAND have a long history of being defective.
-## The RNG seed passed by the bootloader could also potentially be tampered.
+## Do not credit the CPU seeds as an entropy sources at boot.
+## The RDRAND and RDSEED CPU (RNG) instructions are proprietary and closed-source.
+## Numerous implementations of RDRAND and RDSEED have a long history of being defective.
 ## Maximizing the entropy pool at boot is desirable for all cryptographic operations.
-## These settings ensure additional entropy is obtained from other sources to initialize the RNG.
-## Note that distrusting these (relatively fast) sources of entropy will increase boot time.
+## This ensures additional entropy is obtained from other sources to initialize the Linux CRNG.
+## Note that distrusting this (relatively fast) source of entropy will increase boot time.
 ##
-## https://en.wikipedia.org/wiki/RDRAND#Reception
+## https://en.wikipedia.org/wiki/RDRAND
 ## https://systemd.io/RANDOM_SEEDS/
 ## https://www.kicksecure.com/wiki/Dev/Entropy#RDRAND
-## https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/
-## https://x.com/pid_eins/status/1149649806056280069
 ## https://archive.nytimes.com/www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html
 ## https://forums.whonix.org/t/entropy-config-random-trust-cpu-yes-or-no-rng-core-default-quality/8566
+## https://lkml.org/lkml/2022/6/5/271
+## https://lwn.net/Articles/961121/
+## https://lore.kernel.org/lkml/aPFDn-4Cm6n0_3_e@gourry-fedora-PF4VCD3F/
+## https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7055.html
+##
+## KSPP=yes
+## KSPP sets CONFIG_RANDOM_TRUST_CPU=y.
+##
+GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX random.trust_cpu=off"
+
+## Do not credit the bootloader seeds as an entropy source at boot.
+## The RNG seed passed by the bootloader could potentially be tampered.
+## Maximizing the entropy pool at boot is desirable for all cryptographic operations.
+## This ensures additional entropy is obtained from other sources to initialize the Linux CRNG.
+## Note that distrusting this (relatively fast) source of entropy will increase boot time.
+##
+## https://systemd.io/RANDOM_SEEDS/
 ## https://github.com/NixOS/nixpkgs/pull/165355
 ## https://lkml.org/lkml/2022/6/5/271
 ##
 ## KSPP=yes
-## KSPP sets CONFIG_RANDOM_TRUST_BOOTLOADER=y and CONFIG_RANDOM_TRUST_CPU=y.
+## KSPP sets CONFIG_RANDOM_TRUST_BOOTLOADER=y.
 ##
 GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX random.trust_bootloader=off"
-GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX random.trust_cpu=off"

 ## Obtain more entropy during boot as the runtime memory allocator is being initialized.
-## Entropy will be extracted from up to the first 4GB of RAM.
+## Entropy will be extracted from up to the first 4GB of RAM as another source.
+## Note that entropy extracted this way is not cryptographically secure and so is not credited.
+## Maximizing the entropy pool at boot is desirable for all cryptographic operations.
+## This will increase boot time due to interrupting the boot process.
 ## Requires the linux-hardened kernel patch.
 ##
 ## https://www.kicksecure.com/wiki/Hardened-kernel#linux-hardened
--- a/usr/lib/sysctl.d/990-security-misc.conf#security-misc-shared
+++ b/usr/lib/sysctl.d/990-security-misc.conf#security-misc-shared
@ -20,6 +20,7 @@
 ## 5. Networking

 ## For detailed explanations of most of the selected commands, refer to:
+## https://www.kernel.org/doc/html/latest/admin-guide/sysctl/abi.html
 ## https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html
 ## https://www.kernel.org/doc/html/latest/admin-guide/sysctl/fs.html
 ## https://www.kernel.org/doc/html/latest/admin-guide/sysctl/net.html
@ -171,7 +172,7 @@ kernel.perf_event_paranoid=3
 ## Certain "oopses" can sometimes indicate and thwart potential kernel exploitation attempts.
 ## Warnings are messages generated by the kernel to indicate unexpected conditions or errors.
 ## By default, code execution continues regardless of warnings emitted by macros like WARN() and WARN_ON().
-## Note that by forcing kernel panics on oopses and warnings, this exposes the system to targeted denial of service attacks.
+## Note that by forcing kernel panics on oopses and warnings, this exposes the system to targeted denial-of-service attacks.
 ##
 ## https://en.wikipedia.org/wiki/Kernel_panic#Linux
 ## https://en.wikipedia.org/wiki/Linux_kernel_oops
@ -188,7 +189,7 @@ kernel.perf_event_paranoid=3
 #kernel.warn_limit=1

 ## Force immediate system reboots on the occurrence of a single kernel panic.
-## Increases resilience and limits impact of denial of service attacks as system automatically restarts.
+## Increases resilience and limits impact of denial-of-service attacks as system automatically restarts.
 ## Ensures the system does not hang forever if a panic occurs, reducing susceptibility to both cold and warm boot attacks.
 ## Immediate rebooting also prevents persistent information disclosure on panic details that were dumped to screen.
 ##
@ -199,15 +200,44 @@ kernel.perf_event_paranoid=3
 ##
 #kernel.panic=-1

-## Force immediate kernel panic on OOM.
-## This is to avoid security features such as the screen locker, kloak, emerg-shutdown
-## from being arbitrarily terminated when the system starts running out of memory.
+## Force immediate kernel panic on OOM (out of memory) scenarios.
+## Registers a kernel panic whenever the oom_killer is triggered to kill some rouge process based on their OOM score.
+## This prevents security features such as the screen locker, kloak, and emerg-shutdown from being arbitrarily terminated.
+## Enabling these two together creates a risk of userspace-based denial-of-service attacks that maliciously fill memory.
+## This forces immediate system reboot rather than placing any reliance on the oom_killer.
+## Known to cause extreme user experience problems with certain applications as the Tor Browser.
+## Enabling by default requires improved upstream handling of user space OOM better accounting for desktop users.
+##
+## https://en.wikipedia.org/wiki/Out_of_memory
 ## https://forums.whonix.org/t/screen-locker-in-security-can-we-disable-these-at-least-4-backdoors/8128/14
+## https://github.com/KSPP/kspp.github.io/issues/9
 ## https://github.com/Kicksecure/security-misc/issues/324
-## Needs more work.
+##
+## Note that this must be used with kernel.panic=-1 for it to function as intended.
 ##
 #vm.panic_on_oom=2

+## Force immediate kernel panic on certain NMIs (Non-Maskable Interrupts).
+## NMIs are hardware interrupts that cannot be ignored by standard interrupt-masking techniques.
+## NMIs are reserved for critical events that require immediate attention.
+## Panic upon a NMI indicating a serious hardware-level I/O issue to prevent data corruption.
+## Panic upon a NMI indicating uncorrectable memory and hardware errors to prevent data corruption.
+## Panic upon receiving an undefined or unknown NMI.
+## All three must first be tested to ensure there are no pre-existing issues on user hardware.
+## After confirming stability of each they can then be used to prevent data corruption from hardware sources.
+## These are valuable for high-reliability systems where data integrity is critical.
+##
+## https://en.wikipedia.org/wiki/Non-maskable_interrupt
+## https://www.kernel.org/doc/html/latest/trace/events-nmi.html
+## https://0xax.gitbook.io/linux-insides/summary/interrupts/linux-interrupts-6
+## https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/7/html/reference_guide/non-maskable_interrupts
+##
+## Note that these must be used with kernel.panic=-1 for them to function as intended.
+##
+#kernel.panic_on_io_nmi=1
+#kernel.panic_on_unrecovered_nmi=1
+#kernel.unknown_nmi_panic=1
+
 ## Disable the use of legacy TIOCSTI operations which can be used to inject keypresses.
 ## Can lead to privilege escalation by pushing characters into a controlling TTY.
 ## Will break out-dated screen readers that continue to rely on this legacy functionality.
@ -232,6 +262,19 @@ dev.tty.legacy_tiocsti=0
 ##
 kernel.io_uring_disabled=2

+## Disable 32-bit Virtual Dynamic Shared Object (vDSO) mappings.
+## Legacy compatibility feature for superseded glibc versions.
+##
+## https://lore.kernel.org/lkml/20080409082927.BD59E26F992@magilla.localdomain/T/
+## https://lists.openwall.net/linux-kernel/2014/03/11/3
+##
+## KSPP=yes
+## KSPP sets the kernel parameter and does not set CONFIG_COMPAT_VDSO.
+##
+## See /etc/default/grub.d/40_kernel_hardening.cfg for another additional implementation.
+##
+abi.vsyscall32=0
+
 ## 2. User Space:
 ##
 ## https://madaidans-insecurities.github.io/guides/linux-hardening.html#sysctl-userspace
@ -526,7 +569,7 @@ net.ipv6.conf.*.accept_source_route=0
 ## Do not accept IPv6 router advertisements (RAs) and solicitations.
 ## RAs are unsecured and unauthenticated and any device on the local link can send and accept them without verification.
 ## Malicious RAs can activate IPv6 connectivity on dormant hosts leading to unauthorized access.
-## Flooding the network with malicious RAs can lead to denial of service attacks.
+## Flooding the network with malicious RAs can lead to denial-of-service attacks.
 ## Rogue RAs can lead to interception of all network traffic by setting the attacker's system as the default gateway.
 ##
 ## https://datatracker.ietf.org/doc/html/rfc6104
@ -565,6 +608,16 @@ net.ipv6.conf.*.accept_ra=0
 ##
 net.ipv4.tcp_timestamps=0

+## Disable reuse of TIME_WAIT sockets for new outgoing connections.
+## The safety of reusing of TIME_WAIT sockets requires enabling TCP timestamps.
+## The kernel uses timestamps to verify a new connection is not a duplicate segment from an older connection.
+## Hence TIME-WAIT sockets should wait the full timeout period before being made available again.
+## Can lead to port exhaustion on high-traffic networks with numerous short-lived connections.
+##
+## https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux
+##
+net.ipv4.tcp_tw_reuse=0
+
 ## Enable logging of packets with impossible source or destination addresses.
 ## Martian and unroutable packets may be used for malicious purposes.
 ## Recommended to keep a (kernel dmesg) log of these to identify suspicious packets.
@ -572,6 +625,8 @@ net.ipv4.tcp_timestamps=0
 ## Known to cause performance issues, especially on systems with multiple interfaces.
 ##
 ## https://wiki.archlinux.org/title/Sysctl#Log_martian_packets
+## https://www.cyberciti.biz/faq/linux-log-suspicious-martian-packets-un-routable-source-addresses/
+## https://support.scc.suse.com/s/kb/Martian-sources-errors-showing-in-messages-log?language=en_US
 ## https://github.com/Kicksecure/security-misc/issues/214
 ##
 ## The logging of martian packets is currently disabled.
--- a/usr/libexec/security-misc/panic-on-oops#security-misc-shared
+++ b/usr/libexec/security-misc/panic-on-oops#security-misc-shared
@ -24,7 +24,8 @@ sysctl kernel.oops_limit=1
 sysctl kernel.warn_limit=1

 ## Makes the system immediately reboot on the occurrence of a single
-## kernel panic. This reduces the risk and impact of denial of
-## service attacks and both cold and warm boot attacks.
+## kernel panic. This reduces the risk and impact of denial-of-service
+## attacks and both cold and warm boot attacks.
+##
 ## https://docs.kernel.org/admin-guide/sysctl/kernel.html#panic
 sysctl kernel.panic=-1