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: Sun, 9 Oct 2011 14:20:54 +0200 From: Kay Sievers <kay.sievers@...y.org> To: Greg KH <greg@...ah.com> Cc: linux-kernel@...r.kernel.org, lennart@...ttering.net, harald@...hat.com, david@...ar.dk Subject: Re: A Plumber’s Wish List for Linux On Fri, Oct 7, 2011 at 20:59, Greg KH <greg@...ah.com> wrote: > On Fri, Oct 07, 2011 at 01:17:02AM +0200, Kay Sievers wrote: >> * CPU modaliases in /sys/devices/system/cpu/cpuX/modalias: > I need to get off my ass and fix this properly, now that Rafael has done > all of the hard work for sysdev already. Thanks for reminding me. > >> * export ‘struct device_type fb/fbcon’ of ‘struct class graphics’ >> Userspace wants to easily distinguish ‘fb’ and ‘fbcon’ from each other >> without the need to match on the device name. > > Can't we just export a "type" file for the device for these devices? > Is it really just that simple? Yeah, it's just adding a 'struct device_type' with a 'name = "fb/fccon" and DEVTYPE= will appear as a property at the device. So much for getting off my ass. :) >> * module-init-tools: provide a proper libmodprobe.so from >> module-init-tools: >> Early boot tools, installers, driver install disks want to access >> information about available modules to optimize bootup handling. > > What information do they want to know? Resolve the alias database that 'depmod' has created from inside any process. Udev wants to avoid calling ~60 modprobes per bootup for a bunch of device types like USB-hubs which will never have driver to be loaded (optimization). Also the installer and module-update tools sometimes want to query the list of things to load before running all the magic asynchronously (less hacks). In general, the command-line-tool-style of doing complexer system software does not really fit any more into the way we need to do things today. We need proper libraries in the background that can be used by whatever thing needs the information, and the same tools we have already should just be users of their own libraries. We a strict separation of policy and mechanics. Other users should be able the use the 'mechanics' of a tool, without executing any 'policy'. >> * allow user xattrs to be set on files in the cgroupfs (and maybe >> procfs?) > > This shouldn't be that difficult, right? It shouldn't. We just need to be careful here what to export, when to use it, and not to create problems and information leaks for namespaces, which might re-use some of the mount points. Kay -- 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