On Thu, 27 Jun 2024, Yafang Shao wrote: > On Thu, Jun 27, 2024 at 9:02 PM Miroslav Benes <mbenes@xxxxxxx> wrote: > > > > Hi, > > > > > > > Additionally, in our production environment, we need to ensure that > > > > > there are no non atomic replace livepatches in use. For instance, some > > > > > system administrators might still build livepatches outside of our CI > > > > > system. Detecting whether a single livepatch is atomic replace or not > > > > > is not easy. To simplify this, we propose adding a new sysfs attribute > > > > > to facilitate this check. > > > > > > > > > > BTW, perhaps we could introduce a new sysctl setting to forcefully > > > > > forbid all non atomic replace livepatches? > > > > > > > > I like it. This looks like the most reliable solution. Would it > > > > solve your problem. > > > > > > > > Alternative solution would be to forbid installing non-replace > > > > livepatches when there is already installed a livepatch with > > > > the atomic replace. I could imagine that we enforce this for > > > > everyone (without sysctl knob). Would this work for you? > > > > > > Perhaps we can add this sysctl knob as follows? > > > > > > kernel.livepatch.forbid_non_atomic_replace: > > > 0 - Allow non atomic replace livepatch. (Default behavior) > > > 1 - Completely forbid non atomic replace livepatch. > > > 2 - Forbid non atomic replace livepatch only if there is already > > > an atomic replace livepatch running. > > > > I would be more comfortable if such policies were implemented in the > > userspace. It would allow for more flexibility when it comes to different > > use cases. The kernel may provide necessary information (sysfs attributes, > > modinfo flag) for that of course. > > The sysfs attributes serve as a valuable tool for monitoring and > identifying system occurrences, but they are unable to preempt > unexpected behaviors such as the occurrence of mixed atomic replace > livepatch and non atomic replace livepatch. True, but when you have sysfs attributes and eventually modinfo, you can easily write a wrapper around modprobe which would implement any policy that you need. For example, you would see which live patches are installed, which live patches you want to install and decide based on that what to do. You can bail out, install only a subset... You can also integrate the wrapper to your "DevOps" system or so. > If the flexibility of the sysctl knob is limited, then perhaps we > could explore utilizing BPF LSM or fmod_ret as an alternative > implementation? We would simply define the necessary interfaces within > the kernel, and users would have the capability to define their own > policies through bpf programs. It sounds like a big hammer to me. If something like this happens, it might be better to implement it on the module loader level. Anyway, others may feel differently about it. Miroslav
