From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755944AbdAFVDl (ORCPT ); Fri, 6 Jan 2017 16:03:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48576 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752929AbdAFVDe (ORCPT ); Fri, 6 Jan 2017 16:03:34 -0500 Date: Fri, 6 Jan 2017 16:03:04 -0500 From: Jessica Yu To: Rusty Russell Cc: "Luis R. Rodriguez" , 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 , Subash Abhinov Kasiviswanathan , Julia Lawall Subject: Re: kmod: add a sanity check on module loading Message-ID: <20170106210304.GA8640@packer-debian-8-amd64.digitalocean.com> References: <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> <87y3ytc8ka.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <87y3ytc8ka.fsf@rustcorp.com.au> X-OS: Linux eisen.io 3.16.0-4-amd64 x86_64 User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 06 Jan 2017 21:03:07 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +++ Rusty Russell [03/01/17 10:34 +1030]: >"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. I was under the impression that aliases were a userspace concern. i.e., we let kmod tools take care of alias resolution and bookkeeping. I'm getting the feeling we're bending over backwards here to accommodate buggy/untrustworthy userspace (modprobe). If I understand correctly, we're performing this validation work - we're proposing to make the kernel alias-aware - because we can't even trust modprobe's return value, and the proposal is to double check this work ourselves in-kernel. But I thought that request_module() wasn't written to provide these "module is now live and loaded" guarantees in the first place. This seems to be documented in kernel/kmod.c - "Callers must check that the service they requested is now available not blindly invoke it." Isn't it the caller's responsibility to (indirectly) validate request_module's work, to check that the service they want is now there? If a caller doesn't do this, then this is a bug on their side. If it is crucial for get_fs_type() to not fail, then perhaps we should be tightening get_fs_type() instead, be that WARNing if the requested filesystem is still not there (as suggested earlier), or maybe even trying the request again. >> 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.