set `vm.panic_on_oom=2` to prevent security-critical processes such as screen lockers from getting randomly killed by kernel OOM?

[adrelanos]

Kernel OOM kills processes at random - unless configured. The innocent victim might be security-critical processes such as screen lockers.

Therefore vm.panic_on_oom=2 makes sense?

[kees]

I worry that this creates a scenario where userspace can DoS the system. I'm not sure that's a general benefit. Perhaps =1 is a better middle-ground?

[ArrayBolt3]

This does open up a greater risk of DoS, since a process can quickly allocate and write to memory and thus crash the system by exhausting all available memory. In practice though, I don't think the added risk is that large since it's already fairly trivial to DoS the system via memory exhaustion without panic_on_oom - the in-kernel OOM killer generally doesn't get invoked until there is no other option than to invoke it, and so usually a system will end up DoS'd by memory exhaustion once "thrashing" begins (where the kernel starts swapping data between memory and the disk frantically, trying to keep from having to OOM-kill anything). A naive DoS attempt might get OOM-killed without thrashing being invoked, but a more sophisticated one would easily DoS a system even without panic_on_oom. (Users who need to prevent thrashing should use a userspace OOM daemon like systemd-oomd, which can be more aggressive than the kernel's OOM killer.)

I would argue that panic_on_oom isn't a universally good idea for all systems, but it's likely a decent default, especially if combined with kernel.panic=-1 to cause a panic to result in an immediate reboot. That way if userspace does manage to cause a panic, at least the system won't be semi-permanently locked up. It's probably a good idea for users who do use a userspace OOM killer to not set this though, since those users are attempting to avoid a DoS, and if a malicious process consumed memory too quickly, it might panic the system before the userspace OOM killer stops it.