On Wed, Apr 8, 2026 at 7:43 PM Petr Mladek <[email protected]> wrote: > > On Wed 2026-04-08 10:40:10, Yafang Shao wrote: > > On Tue, Apr 7, 2026 at 11:08 PM Petr Mladek <[email protected]> wrote: > > > > > > On Tue 2026-04-07 17:45:31, Yafang Shao wrote: > > > > On Tue, Apr 7, 2026 at 11:16 AM Yafang Shao <[email protected]> > > > > wrote: > > > > > > > > > > On Tue, Apr 7, 2026 at 10:54 AM Song Liu <[email protected]> wrote: > > > > > > > > > > > > On Mon, Apr 6, 2026 at 2:12 PM Joe Lawrence > > > > > > <[email protected]> wrote: > > > > > > [...] > > > > > > > > > > - The regular livepatches are cumulative, have the replace > > > > > > > > > > flag; and > > > > > > > > > > are replaceable. > > > > > > > > > > - The occasional "off-band" livepatches do not have the > > > > > > > > > > replace flag, > > > > > > > > > > and are not replaceable. > > > > > > > > > > > > > > > > > > > > With this setup, for systems with off-band livepatches > > > > > > > > > > loaded, we can > > > > > > > > > > still release a cumulative livepatch to replace the > > > > > > > > > > previous cumulative > > > > > > > > > > livepatch. Is this the expected use case? > > > > > > > > > > > > > > > > > > That matches our expected use case. > > > > > > > > > > > > > > > > If we really want to serve use cases like this, I think we can > > > > > > > > introduce > > > > > > > > some replace tag concept: Each livepatch will have a tag, u32 > > > > > > > > number. > > > > > > > > Newly loaded livepatch will only replace existing livepatch > > > > > > > > with the > > > > > > > > same tag. We can even reuse the existing "bool replace" in > > > > > > > > klp_patch, > > > > > > > > and make it u32: replace=0 means no replace; replace > 0 are the > > > > > > > > replace tag. > > > > > > > > > > > > > > > > For current users of cumulative patches, all the livepatch will > > > > > > > > have the > > > > > > > > same tag, say 1. For your use case, you can assign each user a > > > > > > > > unique tag. Then all these users can do atomic upgrades of their > > > > > > > > own livepatches. > > > > > > > > > > > > > > > > We may also need to check whether two livepatches of different > > > > > > > > tags > > > > > > > > touch the same kernel function. When that happens, the later > > > > > > > > livepatch should fail to load. > > > > > > I still think how to make the hybrid mode more secure: > > > > > > + The isolated sets of livepatched functions look like a good rule. > > > + What about isolating the shadow variables/states as well? > > > > We might consider extending the klp_shadow_* API to support the new > > livepatch tag. > > It would be nice to associate shadow variables with states so that > we could check which shadow variables are used by each livepatch. > > It is partially implemented in my earlier RFC, see > https://lore.kernel.org/all/[email protected]/
This patch is still pending acceptance, but it offers a nice improvement. With your modifications, the remaining task would be to integrate a new replace_set into klp_state and update the API accordingly [...] -- Regards Yafang
