From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754921AbcH2QQb (ORCPT ); Mon, 29 Aug 2016 12:16:31 -0400 Received: from mail-oi0-f51.google.com ([209.85.218.51]:36390 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751314AbcH2QQa (ORCPT ); Mon, 29 Aug 2016 12:16:30 -0400 Date: Mon, 29 Aug 2016 11:16:28 -0500 From: Christopher Arges To: Petr Mladek Cc: live-patching@vger.kernel.org, Josh Poimboeuf , Jessica Yu , Jiri Kosina , Miroslav Benes , linux-kernel@vger.kernel.org Subject: Re: [PATCH] livepatch: add load/unload hooks to objects Message-ID: <20160829161627.GA32390@gmail.com> References: <1472237448-22270-1-git-send-email-chris.j.arges@canonical.com> <1472237448-22270-2-git-send-email-chris.j.arges@canonical.com> <20160829152330.GN4866@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160829152330.GN4866@pathway.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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