Not sure which category this belongs to. security
I want to discuss the viability of many known kargs to set, to get more security for the community (and thus a better reputation of Fedora too).
Also, even if they are not implemented (but only documented or advised, for example if they break on certain old hardware), they could be integrated in the testing suites, to avoid bugs like this where an untested karg breaks kernel features.
I want to go through every proposed karg and discuss its viability for common use, even though this will probably need a specific discussion per karg.
I am referring to this guide and many parts are direct quotes.
If some may already be set, I will remove them.
slab_nomerge
This disables slab merging, which significantly increases the difficulty of heap exploitation by preventing overwriting objects from merged caches and by making it harder to influence slab cache layout.
init_on_alloc=1
init_on_free=1
This enables zeroing of memory during allocation and free time, which can help mitigate use-after-free vulnerabilities and erase sensitive information in memory.
page_alloc.shuffle=1
This option randomises page allocator freelists, improving security by making page allocations less predictable. This also improves performance.
pti=on
This enables Kernel Page Table Isolation, which mitigates Meltdown and prevents some KASLR bypasses.
randomize_kstack_offset=on
This option randomises the kernel stack offset on each syscall, which makes attacks that rely on deterministic kernel stack layout significantly more difficult, such as the exploitation of CVE-2019-18683.
vsyscall=none
This disables vsyscalls, as they are obsolete and have been replaced with vDSO. vsyscalls are also at fixed addresses in memory, making them a potential target for ROP attacks.
debugfs=off
This disables debugfs, which exposes a lot of sensitive information about the kernel.
this causes this bug so it is not currently usable
module.sig_enforce=1
This only allows kernel modules that have been signed with a valid key to be loaded, which increases security by making it much harder to load a malicious kernel module. This prevents all out-of-tree kernel modules, including DKMS modules from being loaded unless you have signed them, meaning that modules such as the VirtualBox or Nvidia drivers may not be usable, although that may not be important, depending on your setup.
this needs to be discussed and documented, the secureboot NVIDIA guides should cover this?
mce=0
This causes the kernel to panic on uncorrectable errors in ECC memory which could be exploited. This is unnecessary for systems without ECC memory.
Spectre / Meltdown mitigations
These might not all apply to all hardware and might not be possible to set for all systems without causing troubles. Not sure if all of them are up-to-date
spectre_v2=on
spec_store_bypass_disable=on
tsx=off
tsx_async_abort=full,nosmt
mds=full,nosmt
l1tf=full,force
nosmt=force
kvm.nx_huge_pages=force
or
mitigations=auto,nosmt
Not sure which is needed today.
This will generally block hyperthreading on affected systems, which will cause performance loss for the sake of security.
BIOS and EFI
Direct memory access (DMA) attacks involve gaining complete access to all of system memory by inserting certain physical devices. This can be mitigated via an IOMMU, which controls the areas of memory accessible to devices, or by blacklisting blocklisting particularly vulnerable kernel modules.
To enable the IOMMU, set the following kernel boot parameters:
intel_iommu=on
amd_iommu=on
You only need to enable the option for your specific CPU manufacturer, but there are no issues with enabling both options.
iommu.passthrough=0
iommu.strict=1
iommu.passthrough=0 disables IOMMU pass-through mode, which will not allow hardware devices to access physical memory directly. Instead, memory accesses by hardware devices will be controlled and mediated by the IOMMU.
When pass-through mode is disabled, the IOMMU acts as an intermediary between the hardware devices and the system memory. It provides memory protection and virtualization features, allowing the operating system to manage and control memory accesses by devices more effectively.
iommu.strict=1 strictly enforces memory access controls, which can enhance security by preventing unauthorized memory access by devices.
These kargs may cause problems on old Hardware and Firmware, or when using devices that require direct memory access. They may also decrease performance in those scenarios
efi=disable_early_pci_dma
This option fixes a hole in the above IOMMU by disabling the busmaster bit on all PCI bridges during very early boot.
This breaks boot at least on Thinkpad T495 Firmware, which is likely a bug in that firmware. It works on other hardware.
Furthermore, Thunderbolt and FireWire are often vulnerable to DMA attacks. To disable them, blacklist blocklist these kernel modules:
install firewire-core /bin/false
install thunderbolt /bin/false
This will have significant missing features. Firewire is not really used though to my knowledge?
RDRAND
RDRAND is a CPU instruction for providing random numbers. It is automatically used by the kernel as an entropy source if it is available; but since it is proprietary and part of the CPU itself, it is impossible to audit and verify its security properties. You are not even able to reverse engineer the code if you wish. This RNG has suffered from vulnerabilities before and often has a weak implementation. It is possible to distrust this feature by setting the following boot parameter:
random.trust_cpu=off
This will increase boot time for generating these random numbers in the kernel. Maybe other speed decreases may occur, but probably not many.
