linux-kernel - Re: [PATCH v14 10/11] livepatch: Remove ordering and refuse loading conflicting patches

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]

Date:   Mon, 17 Dec 2018 17:07:09 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Jiri Kosina <jikos@...nel.org>, Miroslav Benes <mbenes@...e.cz>,
        Jason Baron <jbaron@...mai.com>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        Evgenii Shatokhin <eshatokhin@...tuozzo.com>,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v14 10/11] livepatch: Remove ordering and refuse loading
 conflicting patches

On Thu 2018-12-13 17:06:52, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 10:44:30AM +0100, Petr Mladek wrote:
> > The atomic replace and cumulative patches were introduced as a more secure
> > way to handle dependent patches. They simplify the logic:
> > 
> >   + Any new cumulative patch is supposed to take over shadow variables
> >     and changes made by callbacks from previous livepatches.
> > 
> >   + All replaced patches are discarded and the modules can be unloaded.
> >     As a result, there is only one scenario when a cumulative livepatch
> >     gets disabled.
> > 
> > The different handling of "normal" and cumulative patches might cause
> > confusion. It would make sense to keep only one mode. On the other hand,
> > it would be rude to enforce using the cumulative livepatches even for
> > trivial and independent (hot) fixes.
> > 
> > This patch removes the stack of patches. The list of enabled patches
> > is still needed but the ordering is not longer enforced.
> > 
> > Note that it is not possible to catch all possible dependencies. It is
> > the responsibility of the livepatch authors to decide.
> > 
> > Nevertheless this patch prevents having two patches for the same function
> > enabled at the same time after the transition finishes. It might help
> > to catch obvious mistakes. But more importantly, we do not need to
> > handle situation when a patch in the middle of the function stack
> > (ops->func_stack) is being removed.
> 
> I'm not sure about this patch.  I like the removal of the stacking.  But
> do we really want to enforce no dependencies between non-cumulative
> patches?  It can be done correctly if the user is careful.
> 
> Maybe we should just let users do it if they want to.  And then that
> also would mean less code for us to maintain.
> 
> And as usual, I apologize if I'm either contradicting or repeating past
> versions of myself. :-)

This patch was actually motivated by you. On some conference, we
discussed how to automatize the creation of livepatches. You wanted
to make livepatching more safe in general (by tools, by checks, ...).
Also you always wanted to make things easier and reduce possible
scenarios. I thought that this might be in line with your wishes.

The problem with this patch is that it forces people to use
cumulative patches. I am not sure if everyone is ready for it.

I do not resist on it. But I still think that it makes sense.

Best Regards,
Petr