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]

Date:	Sat, 20 Jul 2013 05:06:29 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tim Chen <tim.c.chen@...ux.intel.com>
Cc:	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 Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
> On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
> > 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.
> 
> The problem is that that doesn't happen when a driver is bound to the
> cpu system device objects.  modprobe is just not called for modules that
> match the cpu modalias in that case.
> 
> If I call modprobe manually for any of the modules in question, it loads
> and works no problem.

OK, I know what's up.  udev has no rule that would allow it to load stuff on
the basis of MODALIAS if DRIVER is set in the event properties.

So, the following rule needs to be added to udev rules for things to work
as before:

DRIVER=="processor", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"

To be precise, I added a file called 80-drivers.rules to /etc/udev/rules.d/
with the following contents:

ACTION=="remove", GOTO="drivers_end"

DRIVER=="processor", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"

LABEL="drivers_end"

but I'm not sure how to propagate this to the udev maintainers.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/