On Mon, May 18, 2026 at 7:23 PM Song Liu <[email protected]> wrote: > On Mon, May 18, 2026 at 2:29 PM Paul Moore <[email protected]> wrote: > [...] > > 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. > > I don't think we can use NOKPROBE_SYMBOL(). There are functions > that we don't want to killswitch, but still want to trace.
That was exactly my point, but we need to figure something out so killswitch doesn't make it easier to cause a regression. -- paul-moore.com
