Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934799AbcLTSwf (ORCPT ); Tue, 20 Dec 2016 13:52:35 -0500 Received: from mail.kernel.org ([198.145.29.136]:43098 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934445AbcLTSwd (ORCPT ); Tue, 20 Dec 2016 13:52:33 -0500 MIME-Version: 1.0 In-Reply-To: <87fuljjua3.fsf@rustcorp.com.au> References: <20161208184801.1689-1-mcgrof@kernel.org> <20161208194930.2816-1-mcgrof@kernel.org> <87k2b2kpdt.fsf@rustcorp.com.au> <20161216083123.GF13946@wotan.suse.de> <87zijvjjm1.fsf@rustcorp.com.au> <87fuljjua3.fsf@rustcorp.com.au> From: "Luis R. Rodriguez" Date: Tue, 20 Dec 2016 12:52:06 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 10/10] kmod: add a sanity check on module loading To: Rusty Russell Cc: Filipe Manana , "Paul E. McKenney" , "linux-doc@vger.kernel.org" , rgoldwyn@suse.com, hare , Jonathan Corbet , Linus Torvalds , linux-kselftest@vger.kernel.org, Andrew Morton , Dan Williams , Aaron Tomlin , rwright@hpe.com, Heinrich Schuchardt , Michal Marek , martin.wilck@suse.com, Jeff Mahoney , Ingo Molnar , Petr Mladek , Dmitry Torokhov , Guenter Roeck , "Eric W. Biederman" , shuah@kernel.org, DSterba@suse.com, Kees Cook , Josh Poimboeuf , Arnaldo Carvalho de Melo , Miroslav Benes , NeilBrown , "linux-kernel@vger.kernel.org" , David Miller , Jessica Yu , Subash Abhinov Kasiviswanathan , Julia Lawall Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2595 Lines: 69 On Mon, Dec 19, 2016 at 6:53 PM, Rusty Russell wrote: > Where does this NULL-deref is the module isn't correctly loaded? No you are right, sorry -- I had confused a failure to mount over null deref, my mistake. >> *Iff* we want a sanity check to verify kmod's umh is not lying to us we >> need to verify after 0 was returned that it was not lying to us. Since kmod >> accepts aliases but find_modules_all() only works on the real module name a >> validation check cannot happen when all you have are aliases. > > request_module() should block until resolution, but that's fundamentally > a userspace problem. Let's not paper over it in kernelspace. OK -- if userspace messes up again it may be a bit hard to prove unless we have a validation debug thing in place, would such a thing in debug form be reasonable ? >> Yes; the kallsyms code does this on Oops. Not really a big issue in >> practice, but a nice fix. >> >> Ok, will bundle into my queue. > > Please submit to Jessica for her module queue, as it's orthogonal > AFAICT. Will do. >> I will note though that I still think there's a bug in this code -- >> upon a failure other "spinning" requests can fail, I believe this may >> be due to not having another state or informing pending modules too >> early of a failure but I haven't been able to prove this conjecture >> yet. > > That's possible, but I can't see it from quickly re-checking the code. > > The module should be fully usable at this point; the module's init has > been called successfully, so in the case of __get_fs_type() it should > now succeed. The module cleans up its init section, but that should be > independent. > > If there is a race, it's likely to be when some other caller wakes the > queue. Moving the wakeup as soon as possible should make it easier to > trigger: > > diff --git a/kernel/module.c b/kernel/module.c > index f57dd63186e6..78bd89d41a22 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -3397,6 +3397,7 @@ static noinline int do_init_module(struct module *mod) > > /* Now it's a first class citizen! */ > mod->state = MODULE_STATE_LIVE; > + wake_up_all(&module_wq); > blocking_notifier_call_chain(&module_notify_list, > MODULE_STATE_LIVE, mod); > > @@ -3445,7 +3446,6 @@ static noinline int do_init_module(struct module *mod) > */ > call_rcu_sched(&freeinit->rcu, do_free_init); > mutex_unlock(&module_mutex); > - wake_up_all(&module_wq); > > return 0; > Will give this a shot, thanks! Luis