linux-kernel - Re: PATCH v6 6/6] livepatch: Add atomic replace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180131215518.cwcxs2atfuzimyxt@treble>
Date:   Wed, 31 Jan 2018 15:55:18 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Evgenii Shatokhin <eshatokhin@...tuozzo.com>
Cc:     Petr Mladek <pmladek@...e.com>, jikos@...nel.org, mbenes@...e.cz,
        Jason Baron <jbaron@...mai.com>, jeyu@...nel.org,
        linux-kernel@...r.kernel.org, live-patching@...r.kernel.org
Subject: Re: PATCH v6 6/6] livepatch: Add atomic replace

On Fri, Jan 26, 2018 at 01:33:04PM +0300, Evgenii Shatokhin wrote:
> >    + The callbacks from the replaced patches are not called. It would be
> >      pretty hard to define a reasonable semantic and implement it.
> 
> At least, it surely simplifies error handling, if these callbacks are not
> called.
> 
> Anyway, I guess, this restriction should be mentioned explicitly in the
> docs. I think this is not obvious for the patch developers (esp. those
> familiar with RPM spec files and such ;-) ).
> 
> What concerns me is that downgrading of the cumulative patches with
> callbacks becomes much more difficult this way.
> 
> I mean, suppose a user has v1 of a cumulative patch installed. Then a newer
> version, v2, is released. They install it and find that it is buggy (very
> unfortunate but might still happen). Now they cannot atomically replace v2
> back with v1, because the callbacks from v1 cannot clean up after v2.
> 
> It will be needed to unload v2 explicitly and then load v1 back, which is
> more fragile. The loading failures are much more unlikely with livepatch
> than with the old kpatch, but they are still possible.
> 
> I have no good solution to this though.

I think the solution is to build a v3, which is basically identical to
v1, except it also has callbacks for cleaning up after v2, if necessary.

It should also be smart enough to deal with the case that v2 was not
installed beforehand.

-- 
Josh