linux-kernel - Re: [PATCH v14 05/11] livepatch: Simplify API by removing registration step

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: <20190103114732.f52qioxi6osl3ett@pathway.suse.cz>
Date:   Thu, 3 Jan 2019 12:47:32 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Joe Lawrence <joe.lawrence@...hat.com>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Miroslav Benes <mbenes@...e.cz>,
        Jason Baron <jbaron@...mai.com>,
        Evgenii Shatokhin <eshatokhin@...tuozzo.com>,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v14 05/11] livepatch: Simplify API by removing
 registration step

On Wed 2018-12-05 14:32:53, Joe Lawrence wrote:
> On Thu, Nov 29, 2018 at 10:44:25AM +0100, Petr Mladek wrote:
> > The possibility to re-enable a registered patch was useful for immediate
> > patches where the livepatch module had to stay until the system reboot.
> > The improved consistency model allows to achieve the same result by
> > unloading and loading the livepatch module again.
> > 
> > Also we are going to add a feature called atomic replace. It will allow
> > to create a patch that would replace all already registered patches.
> > The aim is to handle dependent patches more securely. It will obsolete
> > the stack of patches that helped to handle the dependencies so far.
> > Then it might be unclear when a cumulative patch re-enabling is safe.
> > 
> > It would be complicated to support the many modes. Instead we could
> > actually make the API and code easier to understand.
> > 
> > This patch removes the two step public API. All the checks and init calls
> > are moved from klp_register_patch() to klp_enabled_patch(). Also the patch
> > is automatically freed, including the sysfs interface when the transition
> > to the disabled state is completed.
> > 
> > diff --git a/Documentation/livepatch/livepatch.txt b/Documentation/livepatch/livepatch.txt
> > index 2d7ed09dbd59..d849af312576 100644
> > --- a/Documentation/livepatch/livepatch.txt
> > +++ b/Documentation/livepatch/livepatch.txt
> >
> > +5.4. Removing
> > +-------------
> >  
> > -At this stage, all the relevant sys-fs entries are removed and the patch
> > -is removed from the list of known patches.
> > +Module removal is only safe when there are no users of the underlying
>                                                               ^^^^^^^^^^
> Could a reader confuse "underlying functions" for functions in the
> livepatching-core?  Would "modified functions" or adding "(struct
> klp_func) " make this more specific?
> 
> > +functions. This is the reason why the force feature permanently disables
> > +the removal. The forced tasks entered the functions but we cannot say
>                                          ^^^^^^^^^^^^^
> Same ambiguity here.

I am going to simplify the entire paragraph and replace:

"Module removal is only safe when there are no users of the underlying
functions. This is the reason why the force feature permanently disables
the removal. The forced tasks entered the functions but we cannot say
that they returned back.  Therefore it cannot be decided when the
livepatch module can be safely removed. When the system is successfully
transitioned to a new patch state (patched/unpatched) without being
forced it is guaranteed that no task sleeps or runs in the old code."

with

"Module removal is only safe when there are no users of functions provided
by the module. This is the reason why the force feature permanently
disables the removal. Only when the system is successfully transitioned
to a new patch state (patched/unpatched) without being forced it is
guaranteed that no task sleeps or runs in the old code."

Best Regards,
Petr

PS: Note that the text was there even before this patch. I just moved it
from the section 4.3.