linux-kernel - Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130719231630.GC1701@kroah.com>
Date:	Fri, 19 Jul 2013 16:16:30 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Tim Chen <tim.c.chen@...ux.intel.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
	ak <ak@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to module
 dependency.

On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
> Alas, this is not the one I'd like to apply.
> 
> With that patch applied, new device objects are created to avoid binding the
> processor driver directly to the cpu system device objects, because that
> apparently confuses udev and it starts to ignore the cpu modalias once the
> driver has been bound to any of those objects.
> 
> I've verified in the meantime that this indeed is the case.
> 
> A link to the patch in question: https://patchwork.kernel.org/patch/2830561/
> 
> Greg, I asked you some time ago whether or not it was possible for udev to stop
> autoloading modules that matched the cpu modalias after a driver had been bound
> to the cpu system device objects and you said "no".  However, this time I can
> say with certainty that that really is the case.  So, the question now is
> whether or not we can do anything in the kernel to avoid that confusion in udev
> instead of applying the patch linked above (which is beyond ugly in my not so
> humble opinion)?

udev isn't doing any module loading, 'modprobe' is just being called for
any new module alias that shows up in the system, and all of the drivers
that match it then get loaded.

How is it a problem if a module is attempted to be loaded that is
already loaded?  How is it a problem if a different module is loaded for
a device already bound to a driver?  Both of those should be total
"no-ops" for the kernel.

But, I don't know anything about the cpu code, how is loading a module
causing problems?  That sounds like it needs to be fixes, as any root
user can load modules whenever they want, you can't protect the kernel
from doing that.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/