Re: [PATCH v2 2/2] livepatch: Delete the associated module of disabled livepatch

Yafang Shao
2024-05-09T05:53:55Z

On Thu, May 9, 2024 at 1:20 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Thu, May 09, 2024 at 10:17:43AM +0800, Yafang Shao wrote:
> > On Wed, May 8, 2024 at 3:03 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > >
> > > On Wed, May 08, 2024 at 02:01:29PM +0800, Yafang Shao wrote:
> > > > On Wed, May 8, 2024 at 1:16 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > > > > If klp_patch.replace is set on the new patch then it will replace all
> > > > > previous patches.
> > > >
> > > > A scenario exists wherein a user could simultaneously disable a loaded
> > > > livepatch, potentially resulting in it not being replaced by the new
> > > > patch. While theoretical, this possibility is not entirely
> > > > implausible.
> > >
> > > Why does it matter whether it was replaced, or was disabled beforehand?
> > > Either way the end result is the same.
> >
> > When users disable the livepatch, the corresponding kernel module may
> > sometimes be removed, while other times it remains intact. This
> > inconsistency has the potential to confuse users.
>
> I'm afraid I don't understand. Can you give an example scenario?
>

As previously mentioned, this scenario may occur if user-space tools
remove all pertinent kernel modules from /sys/livepatch/* while a user
attempts to load a new atomic-replace livepatch.

For instance:

User-A User-B

echo 0 > /sys/livepatch/A/enable insmod atomic-replace-patch.ko

From User-A's viewpoint, the A.ko module might sometimes be removed,
while at other times it remains intact. The reason is that User-B
removed a module that he shouldn't remove.

--
Regards
Yafang