On Mon, May 18, 2026 at 2:31 AM Song Liu <[email protected]> wrote: > On Thu, May 14, 2026 at 8:48 PM Paul Moore <[email protected]> wrote: > > On Thu, May 7, 2026 at 3:05 AM Sasha Levin <[email protected]> wrote: > > > > > > When a (security) issue goes public, fleets stay exposed until a patched > > > kernel > > > is built, distributed, and rebooted into. > > > > > > For many such issues the simplest mitigation is to stop calling the buggy > > > function. Killswitch provides that. An admin writes: > > > > > > echo "engage af_alg_sendmsg -1" \ > > > > /sys/kernel/security/killswitch/control > > > > > > After this, af_alg_sendmsg() returns -EPERM on every call without > > > running its body. The mitigation takes effect immediately, and is dropped > > > on > > > the next reboot. > > > > > > A lot of recent kernel issues sit in code paths most installs only have > > > enabled > > > to support a relative minority of users: AF_ALG, ksmbd, nf_tables, vsock, > > > ax25, > > > and friends. > > > > > > For most users, the cost of "this socket family stops working for the > > > day" is > > > much smaller than the cost of running a known vulnerable kernel until the > > > fix > > > land. > > > > > > Assisted-by: Claude:claude-opus-4-7 > > > Signed-off-by: Sasha Levin <[email protected]> > > > --- > > > Documentation/admin-guide/index.rst | 1 + > > > Documentation/admin-guide/killswitch.rst | 159 ++++ > > > Documentation/admin-guide/tainted-kernels.rst | 8 + > > > MAINTAINERS | 11 + > > > include/linux/killswitch.h | 19 + > > > include/linux/panic.h | 3 +- > > > init/Kconfig | 2 + > > > kernel/Kconfig.killswitch | 31 + > > > kernel/Makefile | 1 + > > > kernel/killswitch.c | 798 ++++++++++++++++++ > > > kernel/panic.c | 1 + > > > lib/Kconfig.debug | 13 + > > > lib/Makefile | 1 + > > > lib/test_killswitch.c | 85 ++ > > > tools/testing/selftests/Makefile | 1 + > > > tools/testing/selftests/killswitch/.gitignore | 1 + > > > tools/testing/selftests/killswitch/Makefile | 8 + > > > .../selftests/killswitch/cve_31431_test.c | 162 ++++ > > > .../selftests/killswitch/killswitch_test.sh | 147 ++++ > > > 19 files changed, 1451 insertions(+), 1 deletion(-) > > > create mode 100644 Documentation/admin-guide/killswitch.rst > > > create mode 100644 include/linux/killswitch.h > > > create mode 100644 kernel/Kconfig.killswitch > > > create mode 100644 kernel/killswitch.c > > > create mode 100644 lib/test_killswitch.c > > > create mode 100644 tools/testing/selftests/killswitch/.gitignore > > > create mode 100644 tools/testing/selftests/killswitch/Makefile > > > create mode 100644 tools/testing/selftests/killswitch/cve_31431_test.c > > > create mode 100755 tools/testing/selftests/killswitch/killswitch_test.sh > > > > If we made Lockdown an LSM, we should probably also make killswitch an LSM. > > I don't think killswitch can stack with other LSMs. In fact, killswitch > can be used to bypass other LSMs, for example: > > echo engage security_file_open 0 > /sys/kernel/security/killswitch/control > > will bypass all hooks on security_file_open.
>From my perspective there are two different issues here: should killswitch be a LSM, and should killswitch leverage kprobes to be able to "kill" security related symbols. After all, are we okay with killswitch killing capable() and friends? In my opinion, making killswitch an LSM is more of a procedural item that deals with how we view a capability like killswitch. I personally view killswitch as somewhat similar to Lockdown, which is why I made the suggestion. The use of kprobes, while an interesting idea, presents problems as allowing any kernel symbol to be killed introduces the potential for security regressions. As a reminder, some LSMs, as well as other kernel subsystems, have mechanisms in place to restrict root and/or enforce one-way configuration locks; while many people equate "root" with full control, in many cases today that is not strictly correct. Yes, kprobes have been around for some time, this is not a new problem, but killswitch makes it far more convenient and accessible to do dangerous things with kprobes. If killswitch makes it past the RFC stage without any significant changes to its kill mechanism, we may need to start considering more liberal usage of NOKPROBE_SYMBOL() which I think would be an unfortunate casualty. -- paul-moore.com
