linux-kernel - Re: [PATCH v5 0/3] livepatch: introduce 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: <20180131220811.isgqpf3gwrsnul5k@treble>
Date:   Wed, 31 Jan 2018 16:08:11 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Jason Baron <jbaron@...mai.com>,
        Evgenii Shatokhin <eshatokhin@...tuozzo.com>,
        linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
        jeyu@...nel.org, jikos@...nel.org, mbenes@...e.cz,
        joe.lawrence@...hat.com
Subject: Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On Fri, Jan 26, 2018 at 11:23:26AM +0100, Petr Mladek wrote:
> So, we are talking about a lot of rather non-trivial code.
> IMHO, it might be easier to run just the callbacks from
> the new patch. In reality, the author should always know
> what it might be replacing and what needs to be done.
> 
> By other words, it might be much easier to handle all
> situations in a single script in the new patch. Alternative
> would be doing crazy hacks to prevent the older scripts from
> destroying what we would like to keep. We would need to
> keep in mind interactions between the scripts and
> the order in which they are called.
> 
> Or do you plan to use cumulative patches to simply
> get rid of any other "random" livepatches with something
> completely different? In this case, it might be much more
> safe to disable the older patches a normal way.
> 
> I would suggest to just document the current behavior.
> We should create Documentation/livepatch/cummulative-patches.txt
> anyway.

+1.  Only the new patch (hopefully) knows the details about what is
being reverted.  So it makes sense to ignore the replaced patch's
callbacks, and to only call the new patch's callbacks.

-- 
Josh