linux-kernel - Re: [PATCH] livepatch: add (un)patch hooks

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: <20170727213600.52rwakraq3yddojs@treble>
Date:   Thu, 27 Jul 2017 16:36:00 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Joe Lawrence <joe.lawrence@...hat.com>
Cc:     Petr Mladek <pmladek@...e.com>, live-patching@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jessica Yu <jeyu@...nel.org>,
        Jiri Kosina <jikos@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>,
        Chris J Arges <chris.j.arges@...onical.com>
Subject: Re: [PATCH] livepatch: add (un)patch hooks

On Thu, Jul 27, 2017 at 04:43:58PM -0400, Joe Lawrence wrote:
> On 07/20/2017 12:17 AM, Josh Poimboeuf wrote:
> > - The pre-patch and pre-unpatch hooks can be run before the
> >   patching/unpatching process begins.
> 
> Hi Josh,
> 
> By "(un)patching process" are you referring to the klp_patch at large or
> each klp_object?  ie, would all klp_objects execute their hooks before
> anything is (un)patched?  Just trying to clarify.

I think they can be interleaved: call pre-patch hook for object A, patch
object A, call pre-patch hook for object B, patch object B, etc.  We'll
just have to document that each hook is specific to its own object, and
no assumptions can be made about the state of other objects.

So maybe the pre-patch hooks could be called from klp_patch_object() and
pre-unpatch hooks could be called from klp_unpatch_object().  That way
they're called from both patch enable/disable and module coming/going
contexts.

Or maybe it would be cleaner to call the hooks from the *callers* of
klp_patch/unpatch_object().  That would mean a couple of more call
sites, but at least the locations of the pre- hooks would be more
symmetrical with the post- hook locations.  For example,
klp_module_coming() would have both pre- and post- hook calls.

> > - The post-patch and post-unpatch hooks will need to be run from either
> >   klp_complete_transition() or klp_module_coming/going(), depending on
> >   whether the to-be-patched module is already loaded or is being
> >   loaded/unloaded.
> 
> You're suggesting that post-(un)patch-hooks:
> 
>   1 - Notify klp_objects when a KLP_(UN)PATCHED transition completes

Right. (From klp_complete_transition())

> and for subsequently loaded klp_objects (ie modules):
> 
>   2 - On load - notify it with current KLP_(UN)PATCHED state,
>       Steady state - same as (1) above.

Right. (From klp_module_coming/going())

-- 
Josh