Hardened profile may be setting unsuitable kernel parameters?

[8573]

Describe the bug https://github.com/NixOS/nixpkgs/blob/fbb76f6ace21d8f1a3956e6f329e404cad4f6136/nixos/modules/profiles/hardened.nix#L34-L39 I don't know enough to say conclusively that this is a problem, but I see it said in https://github.com/anthraxx/linux-hardened/issues/37 that the kernel parameters slub_debug=P and page_poison=1, which are set by the NixOS hardened profile, conflict with another parameter enabled by default by the linux-hardened patchset that we use as of #84522. I see that the maintainer @anthraxx in general seems to oppose these options and in particular says that "vanilla page poisoning [...] collides with the page verify code of hardened", though I don't know which option specifically is "vanilla page poisoning" (I assume page_poison=1).

I've read the documentation on these parameters at https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html, but I don't see anything particularly enlightening about them, so I leave to more knowledgeable people whether this is a problem in the NixOS hardened profile.

Notify maintainers @joachifm @emilazy

[stale[bot]]

I marked this as stale due to inactivity. → More info

[half-duplex]

KSPP says init_on_alloc+init_on_free supersede both slub_debug=P and page_poison=1. https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings

# Wipe slab and page allocations (since v5.3) # Instead of "slub_debug=P" and "page_poison=1", a single place can control memory allocation wiping now. # The init_on_free is only needed if there is concern about minimizing stale data lifetime. CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y CONFIG_INIT_ON_FREE_DEFAULT_ON=y

# Wipe slab and page allocations (Since v5.3; supersedes "slub_debug=P" and "page_poison=1" below) # See CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y and CONFIG_INIT_ON_FREE_DEFAULT_ON=y above. init_on_alloc=1 init_on_free=1

Additionally, use of slub_debug seems to disable kernel pointer hashing. https://github.com/torvalds/linux/commit/792702911f581f7793962fbeb99d5c3a1b28f4c3

[emilazy]

I agree, there's lots of improvements that could be made here; most of the hardened kernel config is from back in the grsecurity days and out of date or even in some cases harmful (e.g. BPF_JIT_ALWAYS_ON may arguably be better security posture these days than disabling it due to the interpreter's use as ROP gadgets). kconfig-hardened-check is a good source of other ideas for tweaks here.

I meant to get to this years ago but at this point it seems unlikely I will any time soon. I'll try my best to review any PRs to improve the hardened profile's kernel config as I think it's an important part of its value-add.

[joachifm]

To elaborate on the above: the parameters (that were set by me, anyway) were based on KSPP recommendations at that time and assumed a vanilla kernel.

If we are now using a hardened patchset it seems prudent to also rely on their config defaults. I see no particular reason to override them (and if that is needed we should probably try to change the hardened patchset upstream first).

[joachifm]

@8573 I'd be happy to accept a PR that updated the kernel parameters. I agree with your interpretation of "vanilla page poisoning" (I take it that the hardened patchset provides an alternative page sanitisation mechanism).

I don't have bandwidth to keep up with what this patchset is doing, nor the pedigree of whatever non-vanilla mitigations the patchset provides. I think it makes sense to follow their config defaults and recommendations for parameters, if we are to use the patchset.

[surfaceflinger]

Not only kconfig should be improved, but hardened kernel should also switch to being built with latest clang and its options like CFI which is supported on both x86_64 and aarch64.

Another good tweak in hardened profile would be bind mounting everything as noexec except from /nix/store and directories like /var/lib/flatpak/app if such services are used

[melvyn2]

With page_poison=1, my hardened VM (x86_64 kvm) shuts down fully during kernel init (I don't have any logs). Removing that parameter allows it to work normally again. Running latest unstable with hardened profile and linux-hardened.