From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757397AbdACCB7 (ORCPT ); Mon, 2 Jan 2017 21:01:59 -0500 Received: from ozlabs.org ([103.22.144.67]:37333 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757370AbdACCBh (ORCPT ); Mon, 2 Jan 2017 21:01:37 -0500 From: Rusty Russell To: "Luis R. Rodriguez" 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.o rg" , David Miller , Jessica Yu , Subash Abhinov Kasiviswanathan , Julia Lawall Subject: Re: [RFC 10/10] kmod: add a sanity check on module loading In-Reply-To: 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> <87a8bqja3i.fsf@rustcorp.com.au> User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 03 Jan 2017 10:34:53 +1030 Message-ID: <87y3ytc8ka.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Luis R. Rodriguez" writes: >> Maybe a similar hack for try_then_request_module(), but many places seem >> to open-code request_module() so it's not as trivial... Hi Luis, Jessica (who is the main module maintainer now), Back from break, sorry about delay. > Right, out of ~350 request_module() calls (not included try requests) > only ~46 check the return value. Hence a validation check, and come to > think of it, *this* was the issue that originally had me believing > that in some places we might end up in a null deref --if those open > coded request_module() calls assume the driver is loaded there could > be many places where a NULL is inevitable. Yes, assuming success == module loade is simply a bug. I wrote try_then_request_module() to attempt to encapsulate the correct logic into a single place; maybe we need other helpers to cover (most of?) the remaining cases? > Granted, I agree they > should be fixed, we could add a grammar rule to start nagging at > driver developers for started, but it does beg the question also of > what a tightly knit validation for modprobe might look like, and hence > this patch and now the completed not-yet-posted alias work. I really think aliases-in-kernel is too heavy a hammer, but a warning when modprobe "succeeds" and the module still isn't found would be a Good Thing. > Would it be worthy as a kconfig kmod debugging aide for now? I can > follow up with a semantic patch to nag about checking the return value > of request_module(), and we can have 0-day then also complain about > new invalid uses. Yeah, a warning about this would be win for sure. BTW, I wrote the original "check-for-module-before-loading" in module-init-tools, but I'm starting to wonder if it was a premature optimization. Have you thought about simply removing it and always trying to load the module? If it doesn't slow things down, perhaps simplicity FTW? Thanks, Rusty.