| 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
| ||
|
Date: Fri, 19 Jul 2013 23:38:04 +0200 From: "Rafael J. Wysocki" <rjw@...ysocki.net> To: Tim Chen <tim.c.chen@...ux.intel.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org> 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 Friday, July 19, 2013 11:08:49 AM Tim Chen wrote: > On Fri, 2013-07-19 at 16:49 +0200, Rafael J. Wysocki wrote: > > > > > > This should cause udev to load the crct10dif_pclml module when cpu > > > > > > support the PCLMULQDQ (feature code 0081). I did my testing during > > > > > > development on 3.10 and the module was indeed loaded. > > > > > > > > > > > > However, I found that the following commit under 3.11-rc1 broke > > > > > > the mechanism after some bisection. > > > > > > > > > > > > commit ac212b6980d8d5eda705864fc5a8ecddc6d6eacc > > > > > > Author: Rafael J. Wysocki <rafael.j.wysocki@...el.com> > > > > > > Date: Fri May 3 00:26:22 2013 +0200 > > > > > > > > > > > > ACPI / processor: Use common hotplug infrastructure > > > > > > > > > > > > Split the ACPI processor driver into two parts, one that is > > > > > > non-modular, resides in the ACPI core and handles the enumeration > > > > > > and hotplug of processors and one that implements the rest of the > > > > > > existing processor driver functionality. > > > > > > > > > > > > Rafael, can you check and see if this can be fixed so those optimized > > > > > > crypto modules for Intel cpu that support them can be loaded? > > > > > > > > > > I think this is an ordering issue between udev startup and the time when > > > > > devices are registered. > > > > > > > > Something that can be fixed? > > > > > > I'm sure it can be fixes, but I'm not sure whether it's a udev bug or real > > > breakage in the kernel yet. I need to figure out that part. > > > > OK > > > > I wonder if the appended patch makes the issue go away for you? > > > > Rafael, the patch did fix the cpu feature based module loading issue. > Thanks for your quick response. 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)? 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/
Powered by blists - more mailing lists