On Mon, May 18, 2026 at 4:57 PM Paul Moore <[email protected]> wrote: > > 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.
killswitch is making it easier to fix a CVE. It can surely make it easier to cause a regression. AFAICT, the only protection here is "it is only for root". Thanks, Song
