oops=panic might be another good kernel parameter to use. This makes the kernel panic on certain errors (oops) to prevent the kernel from continuing running a flawed process. Kernel exploits can also cause oopses. This is similar to
This can also be set with
kernel.panic_on_oops=1 with sysctl.
The problem with this is that sometimes buggy drivers will cause harmless oopses which will cause unnecessary kernel panics. This might be less likely if this is enabled in a virtual machine.
This was suggested to Tails but they didn’t accept it as it would cause many hardware-related kernel panics.
A good way around the errors was suggested.
I think a nice, albeit slightly hacky compromise would be to have kernel.panic_on_oops=0 upon boot, and then set kernel.panic_on_oops=1 after the GNOME desktop starts up if the kernel has not oopsed by then. That would opportunistically provide a security improvement on supported hardware.
For some reason, the Tails devs didn’t include this, they didn’t seem to notice it at all.
A good way to implement this would be to add
sysctl kernel.panic_on_oops=1 inside /etc/X11/Xsession.d/50panic_on_oops.
More kernel parameters were mentioned but nothing came of them.
Additional options I am looking into are reboot=cold (may make certain types of cold-boot attacks harder if memory is not removed from the system), acpi=copy_dsdt (may harden the system slightly from buggy BIOSes), and elevator=deadline (might reduce kernel surface area, with a nice side effect of improving USB and SSD performance). I may post rational for them as well if they turn out to be useful security-wise.
Does anyone know if these would have any security advantage? I can’t see how they would.
Another issue was opened about the panic_on_oops part but no useful information is there.
Checking the Tails issue tracker for kernel related issues may have more useful information but I couldn’t find much more there.