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
