Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932232AbbELIZl (ORCPT ); Tue, 12 May 2015 04:25:41 -0400 Received: from cantor2.suse.de ([195.135.220.15]:51217 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752634AbbELIZi (ORCPT ); Tue, 12 May 2015 04:25:38 -0400 Date: Tue, 12 May 2015 10:25:34 +0200 (CEST) From: Miroslav Benes To: Minfei Huang cc: Minfei Huang , jpoimboe@redhat.com, sjenning@redhat.com, jkosina@suse.cz, vojtech@suse.cz, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] livepatch: Prevent to enable uninitialized patch In-Reply-To: Message-ID: References: <1431313066-3102-1-git-send-email-mhuang@redhat.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6334 Lines: 177 On Mon, 11 May 2015, Minfei Huang wrote: > On 05/11/15 at 02:02P, Miroslav Benes wrote: > > On Mon, 11 May 2015, Minfei Huang wrote: > > > > > From: Minfei Huang > > > > > > The previous patches can be applied, while the corresponding module is > > > loaded. Now the code cannot handle correct behavior to deal with the > > > case that the patch fail to be initialized when the module is being > > > loaded. > > > > > > In general, the patch will do relocation (if necessary) and > > > obtain/verify function address before we start to enable patch. But we > > > can still trigger to enable the patch (disable the patch firstly, then > > > enable it), although the patch fail to be initialized in the function > > > klp_module_notify_coming. > > > > > > To fix it, we can make obj->mod to NULL, if the object fails to be > > > initialized. > > > > > Hi, Miroslav. > > This patch is used to prevent the patch to be enabled. I will use the > code to explain what I want to show you. > > 1) Patched a patch to fix the issue for module A. > 2) livepatch will try to enable the patch, while the corresponding > module is loaded ( call klp_module_notify_coming ) > 3) Firstly, livepatch will do the instruction "obj->mod = mod", whatever > the result of klp_module_notify_coming is. > 4) livepatch may fail to call the klp_init_object_loaded or > klp_enable_object > 5) klp_module_notify_coming returns > > 6) For the userspace, we can enable the patch again ( disable the patch > firstly, then enable the patch from the sysfs ) > 7) In order to enable the patch, livepatch will call __klp_enable_patch > 8) we can pass the limitation (klp_is_object_loaded), because the value > of obj->mod is not NULL ( the obj->mod obtains the value from the step 3 ) > 9) the patch may be applied, although the patch is not initialized, if > the value of func->old_addr is not NULL > > >From the above description, we can see the uninitialized patch ( the > patch should be initialized by the klp_init_object_loaded in general ) > can be applied to the kernel. Hi, thanks for an explanation. This is really valid. Concerning 9), func->old_addr should not be used for the modules (I know we had some discussion about that). So it could happen that func->old_addr is not initialized as you describe and the user gets warning from klp_enable_func. This should be fixed as you proposed. Please resend as Jiri requested Thanks Miroslav > > Thanks > Minfei > > > > Signed-off-by: Minfei Huang > > > > Hi, > > > > just to be sure, is the following what makes you worried? > > > > The module comes and our notifier is called. We verify that it needs to be > > patched and we call klp_module_notify_coming where the object (for this > > module) is enabled. But that could fail somewhere and we print warning to > > the log (pr_warn). Now, you can disable and enable patch, during which the > > object for this very module is enabled again. And it could fail again. > > > > Is this correct? Do you want to prevent printing of the warning again and > > again to the log? > > > > It could happen that the first enablement could fail because of something > > which would not be true for the second try. In such case the module would > > not be patched with your fix (it would be skipped in __klp_enable_patch > > loop). > > > > It is possible that I do not understand the changelog and the patch > > correctly, so please shed some light on this if necessary... > > > > Thanks, > > Miroslav > > > > > --- > > > kernel/livepatch/core.c | 23 +++++++++++++---------- > > > 1 file changed, 13 insertions(+), 10 deletions(-) > > > > > > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c > > > index 284e269..4bbcdda 100644 > > > --- a/kernel/livepatch/core.c > > > +++ b/kernel/livepatch/core.c > > > @@ -883,30 +883,30 @@ int klp_register_patch(struct klp_patch *patch) > > > } > > > EXPORT_SYMBOL_GPL(klp_register_patch); > > > > > > -static void klp_module_notify_coming(struct klp_patch *patch, > > > +static int klp_module_notify_coming(struct klp_patch *patch, > > > struct klp_object *obj) > > > { > > > struct module *pmod = patch->mod; > > > struct module *mod = obj->mod; > > > - int ret; > > > + int ret = 0; > > > > > > ret = klp_init_object_loaded(patch, obj); > > > if (ret) > > > - goto err; > > > + goto out; > > > > > > if (patch->state == KLP_DISABLED) > > > - return; > > > + goto out; > > > > > > pr_notice("applying patch '%s' to loading module '%s'\n", > > > pmod->name, mod->name); > > > > > > ret = klp_enable_object(obj); > > > - if (!ret) > > > - return; > > > > > > -err: > > > - pr_warn("failed to apply patch '%s' to module '%s' (%d)\n", > > > - pmod->name, mod->name, ret); > > > +out: > > > + if (ret) > > > + pr_warn("failed to apply patch '%s' to module '%s' (%d)\n", > > > + pmod->name, mod->name, ret); > > > + return ret; > > > } > > > > > > static void klp_module_notify_going(struct klp_patch *patch, > > > @@ -930,6 +930,7 @@ disabled: > > > static int klp_module_notify(struct notifier_block *nb, unsigned long action, > > > void *data) > > > { > > > + int ret = 0; > > > struct module *mod = data; > > > struct klp_patch *patch; > > > struct klp_object *obj; > > > @@ -955,7 +956,9 @@ static int klp_module_notify(struct notifier_block *nb, unsigned long action, > > > > > > if (action == MODULE_STATE_COMING) { > > > obj->mod = mod; > > > - klp_module_notify_coming(patch, obj); > > > + ret = klp_module_notify_coming(patch, obj); > > > + if (ret) > > > + obj->mod = NULL; > > > } else /* MODULE_STATE_GOING */ > > > klp_module_notify_going(patch, obj); > > > > > > -- > > > 2.2.2 > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe live-patching" in > > > the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > -- > > Miroslav Benes > > SUSE Labs > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/