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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 1 Feb 2018 11:15:43 +0300
From:   Evgenii Shatokhin <eshatokhin@...tuozzo.com>
To:     Josh Poimboeuf <jpoimboe@...hat.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 01.02.2018 00:55, Josh Poimboeuf wrote:
> 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.
> 

I thought about this, but such patches would be very difficult to 
maintain. It seems better to explicitly unload v2 and then load v1 back 
in such cases.

In addition, releasing v3 takes some time (build + appropriate QA 
procedures) while the users may want to do something about the faulty 
patch "right here, right now". This is what "downgrade" option is for.

Anyway, livepatch is much more likely to apply the patches successfully 
than the old kpatch core. So it should be OK to simply unload v2 and 
then load v1 in such (hopefully rare) scenarios.

As I said, the current behaviour is acceptable, esp. when it is 
documented. Implementation of livepatch is already complex enough.

Regards,
Evgenii