Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive

[Michal Hocko <mhocko@suse.com>]

On Mon 11-05-26 11:55:41, Sasha Levin wrote:
> On Mon, May 11, 2026 at 04:25:57PM +0200, Michal Hocko wrote:
> > On Mon 11-05-26 09:56:30, Sasha Levin wrote:
> > > On Mon, May 11, 2026 at 03:49:24PM +0200, Michal Hocko wrote:
> > > > On Mon 11-05-26 09:39:32, Sasha Levin wrote:
> > > > > On Mon, May 11, 2026 at 03:07:51PM +0200, Michal Hocko wrote:
> > > > > In a similar way to how they would know if a given livepatch is safe to apply -
> > > > > ideally it would be communicated by the vendor/distro/kernel team.
> > > >
> > > > You have missed my point. KLP takes an extra steps to make sure patching
> > > > a particular function is safe to modify or to put the change into the
> > > > effect.
> > > 
> > > Safety checks like making sure the patched function is on the stack, or did you
> > > mean something else?
> > 
> > Yes, exactly what LP infrastructure already provides.
> 
> But do we actually need it here?

If not then you can simply systemtap or use BPF to inject the code. In
other words we have several ways how to runtime modify the kernel so
before yet another interface is provided (with a non-trivial amount of
code and very limited functionality) you should really start by
describing why none of the existing one is fitting well.

I do understand your argument that solutions based on loading a module
might have an additional step to deal with (AFAIK you do not need to
build your own kernel to deploy your key) is that a brohibitive
roadblock? We also do have fault injection which is much less convenient
because of all the existing constraines but can those be elevated?

So nothing really against playing with ideas nad LLMs to generated a
quick PoC. That is all good but for this to be considered more seriously
I think we really need to think deeper whether the existing
infrastructure is really not fitting and if not whether it could be
changed to cover more usecase like the one you have mentioned here and I
believe it is something worth thinking about.
-- 
Michal Hocko
SUSE Labs