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. Thanks, Song
