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-next>] [day] [month] [year] [list]
Date:	Sat, 20 Jul 2013 12:56:54 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Kay Sievers <kay@...y.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	systemd-devel@...ts.freedesktop.org
Subject: udev: New default rule for autoloading kernel modules matching CPU modalias

Hi Kay,

After a recent change present in 3.11-rc1 there is a driver, called processor,
that can be bound to the CPU devices whose sysfs directories are located under
/sys/devices/system/cpu/.  A side effect of this is that, after the driver has
been bound to those devices, the kernel adds DRIVER=processor to ENV for CPU
uevents and they don't match the default rule for autoloading modules matching
MODALIAS:

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

any more.  However, there are some modules whose module aliases match specific
CPU features through the modalias string and those modules should be loaded
automatically if a compatible CPU is present.  Yet, with the processor driver
bound to the CPU devices the above rule is not sufficient for that, so we need
a new default udev rule allowing those modules to be autoloaded even if the
CPU devices have drivers.

On my test systems I added the following rule for that:

ACTION="add", SUBSYSTEM=="cpu", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"

in a separate file, but I'm not a udev expert, so I guess it may be done in a
better way.

Can you please consider adding such a rule to the default set of udev rules?

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ