Shouldn’t this also prevent self-destruction? [LWN.net]

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 16:11 UTC (Fri) by sashal (✭ supporter ✭, #81842)
In reply to: Shouldn’t this also prevent self-destruction? by mb
Parent article: killswitch for short-term emergency vulnerability mitigation

> Having a root-feature that can override any kernel function is a *very* big hammer. I'd rather like to not have it.

We already have pretty much the same functionality with livepatch, bpf, or heck, the good old tracing infra. Lockdown is supposed to be the "killswitch" for any of these potentially self-harming things, no?

to post comments

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 16:53 UTC (Fri) by mb (subscriber, #50428) [Link] (2 responses)

Yes, I know that we already have many of these things and now we are adding another one.
This is the wrong direction. We should reduce what root is able to do and reduce the attack surface of the kernel.

> Lockdown is supposed to be the "killswitch" for any of these potentially self-harming things, no?

Right. But is this really a practical solution? If I need one of these things, I have to enable all of them.
There is basically no use case for killswitch, livepatch and tracing on a desktop, but bpf is still useful. Can't use lockdown, and get a free livepatch/killswitch.

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 17:00 UTC (Fri) by sashal (✭ supporter ✭, #81842) [Link]

This sounds like you've listed another usecase for killswitch: use it to remove all the functionality you don't want, followed by killswitching ks_attr_open (or something like that) to disable killswitch itself :)

Shouldn’t this also prevent self-destruction?

Posted May 9, 2026 6:21 UTC (Sat) by pabs (subscriber, #43278) [Link]

livepatch is very useful on a desktop, I don't want to have to reboot for security updates their either.