linux-kernel - Re: [PATCH] livepatch: add load/unload hooks to objects

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, 29 Aug 2016 11:16:28 -0500
From:   Christopher Arges <chris.j.arges@...onical.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     live-patching@...r.kernel.org,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jessica Yu <jeyu@...hat.com>, Jiri Kosina <jikos@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] livepatch: add load/unload hooks to objects

On Mon, Aug 29, 2016 at 05:23:30PM +0200, Petr Mladek wrote:
> On Fri 2016-08-26 13:50:27, Chris J Arges wrote:
> > It can be useful to execute hook functions whenever a livepatch is applied
> > or unapplied to a particular object. Currently this is possible by writing
> > logic in the __init function of the livepatch kernel module. However to
> > handle executing functions when a module loads requires an additional
> > module notifier to be set up with the correct priority.
> > 
> > By using load/unload hooks we can execute these functions using the
> > existing livepatch notifier infrastructure and ensure consistent ordering
> > of notifications.
> > 
> > The load hook executes right before enabling functions, and the unload hook
> > executes right after disabling functions.
> 
> Could you please provide an example(s), what these hooks will be
> useful for?
> 
> The callbacks will still need to be implemented in the patch module.
> If they are generally useful, it would make sense to implement them
> in the livepatch code directly, so they get more review and are
> shared.
> 
> Best Regards,
> Petr

These hooks could be used as a yet another tool to implement a specific patch.
And yes, the callbacks to these hooks will be part of the patch module.

If there are 'hooks' that are applicable generically to livepatch they should
absolutely go into the core code.

As an example, CVE-2015-5307 requires that a bit be set in the exception bitmap
in order to handle #AC exceptions. One could write code in the init function of
the patch that checks if the module is loaded and then applies this fix. Or if
hooks are available, write a load hook that sets this structure whenever the
patch is loaded and the kvm module is loaded. In the future when patch
unloading is possible, one could also write an unload hook to return the
exception bitmap back to normal as the patched function(s) may not be available
any longer.

Another example is CVE-2016-2117. Here we need to unset NETIF_F_SG on a
particular device. If the device is already loaded we need a way to fixup
hw_features on an already allocated network device. Again this could be done
in the init code of the patch, but a nicer solution would be to do this on a
load/unload hook appropriately.

In general these hooks would help to better handle what needs to be setup before
we patch and cleanup after we unpatch. While one could write their own code and
notifiers in the patch init (and later exit) to do this, having a hook makes
this implementation cleaner and can tie it to a specific object. In addition,
tools like kpatch-build for livepatch (or whatever comes in the future) could
also utilize these hooks in much of the same way that kpatch does already.

--chris