Weekly Edition
Return to the Kernel page
| |||||||||||||
First version of kmod released
A new library libkmod and set of tools (kmod-*) for handling kernel modules has been announced. The idea is to give early boot tools, installers, udev, and others an easy way to query and control kernel modules via a library, rather than using modprobe. "In a recent Linux Desktop (and also several embedded systems) when computer is booting up, udev is responsible for checking available hardware, creating device nodes under /dev (or at least configuring their permissions) and loading kernel modules for the available hardware. In a kernel from a distribution it's pretty common to put most of the things as modules. Udev reads the /sys filesystem to check the available hardware and tries to load the necessary modules. This translates in hundreds of calls to the modprobe binary, and in several of them just to know the module is already loaded, or it's in-kernel. With libkmod it's possible for udev with a few lines of code to do all the job, benefiting from the configurations and indexes already opened and parsed." The project also provides work-alike programs for insmod, lsmod, rmmod, and an incomplete version of modprobe that use libkmod, with plans to complete the set. (Thanks to Luis Felipe Strano Moraes.)
(Log in to post comments)
First version of kmod released Posted Dec 15, 2011 21:12 UTC (Thu) by josh (subscriber, #17465) [Link]
This looks potentially awesome, as a means of simplifying and speeding up the boot process. Odd, though, that this didn't get announced on LKML or similar. How did LWN come across this blog entry?
First version of kmod released Posted Dec 15, 2011 21:16 UTC (Thu) by jake (editor, #205) [Link]
> How did LWN come across this blog entry?
We were pointed to it by Luis Felipe Strano Moraes, who I should have thanked in the blurb (and have done so now).
jake
First version of kmod released Posted Dec 15, 2011 21:33 UTC (Thu) by gsbarbieri (subscriber, #10537) [Link]
Hi Josh,
Indeed one of interest of this project by our company, ProFUSION embedded systems, is the boot time impact. Actually we've done speed improvements, reducing memory allocation, fragmentation and using mmap() to read the binary index, among other items.
But that is not the biggest benefit, it can be much more clean to have systemd and udev to use this library, avoiding fork/exec of modprobe dozen of times, most of them to resolve an alias to an empty list (built-in modules).
As for the announcement, err... blame Lucas! We split the announcement duty among ourselves, I posted to some places, Luis Felipe posted to others (like LWN) and he was the one to post to LKML, udev and systemd mailing lists... but developers are sometimes too reluctant to write human readable texts ;-) [he is postponing the announcement to debug on issue already found]
First version of kmod released Posted Dec 15, 2011 22:11 UTC (Thu) by josh (subscriber, #17465) [Link]
> But that is not the biggest benefit, it can be much more clean to have systemd and udev to use this library, avoiding fork/exec of modprobe dozen of times, most of them to resolve an alias to an empty list (built-in modules).
Exactly what I meant when I said "simplifying". :)
modprobe does seem like the biggest remaining source of fork/exec in the boot process. More generally, it seems like an area where appropriately privileged programs ought to just make a few syscalls rather than launching a program.
libkmod could also help clean up programs which need to build and load kernel modules on the fly, for crazy purposes such as live-patching the kernel (ksplice) or introducing tracing code (systemtap or similar). Such programs should not need to build a .ko on disk and fork/exec insmod.
First version of kmod released Posted Dec 15, 2011 22:25 UTC (Thu) by demarchi (subscriber, #67492) [Link]
Yeah... I should have sent to the mailing lists. But in my defense I did the blog post at least.
Soon I'll send the second version due to the bug we fixed today, so maybe let's send to lkml for the second version.
First version of kmod released Posted Dec 16, 2011 13:19 UTC (Fri) by nix (subscriber, #2304) [Link]
Not just that. Right now, if you want to find out programmatically where a module's .ko file is located you have to use a combination of modprobe -l (which is marked deprecated, so using it even now means your program will break sooner or later when the option is removed) and hardwired knowledge of the contents of /lib/modules/$version. Alternatively you can use find(1), which is slow and can't handle module aliases. This is all extremely ugly and fragile and means that moving your modules somewhere else requires modifying N different programs. libkmod looks like it will replace that with kmod_new(); kmod_module_new_from_name(); kmod_module_get_path(). It can't come soon enough, as far as I'm concerned.
First version of kmod released Posted Dec 15, 2011 22:04 UTC (Thu) by alvieboy (subscriber, #51617) [Link]
Any real-world figures about what gains can be extracted from using this new tool ? And what are its drawbacks ?
Avoiding deep "modprobe" calls is a good thing, but it's also something that could be embedded in udev itself. modprobe is not that complex, nor insmod is.
udev could just load all apropriate data on startup, speed up all modprobe and notifications, and just release the extra memory after.
MHO.
Álvaro
First version of kmod released Posted Dec 15, 2011 22:09 UTC (Thu) by vrfy (subscriber, #13362) [Link]
That's exactly what udev will do _with_ this lib. Efficient modprobe alias resolving is not that trivial.
First version of kmod released Posted Dec 15, 2011 22:20 UTC (Thu) by gsbarbieri (subscriber, #10537) [Link]
Hi Alvaro,
At the moment we're not focused on speed or benchmarks, the existing speedups were only implemented as we were creating the new code and could do it with the same effort as creating a bit slower/traditional version. But we expect them to be done later, after we know it is working properly :-)
Indeed insmod is stupidly simple, modprobe is bit more complex but manageable for sure.
And yes, it could be in udev, actually udev may static link to it and be the only user... if that happens we will ask Kay to merge libkmod into udev codebase and continue as a single project. Let's have libkmod to mature and see what's happen, at the moment it is new and needs a faster release cycle.
First version of kmod released Posted Dec 15, 2011 22:23 UTC (Thu) by alvieboy (subscriber, #51617) [Link]
Thanks for your excellent answer :) I'll watch your work closely from now on.
Best,
First version of kmod released Posted Dec 16, 2011 0:18 UTC (Fri) by jengelh (subscriber, #33263) [Link]
>udev may static link to it and be the only user...
There is still insmod/modprobe, i.e. the tool the user will use to manually load his just-compiled module.
First version of kmod released Posted Dec 16, 2011 0:30 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
remember that almost all of this gets eliminated if you have the drivers compiled in instead of doing everything with modules.
Distros need modules, but servers seldom do.
First version of kmod released Posted Dec 16, 2011 0:58 UTC (Fri) by linusw (subscriber, #40300) [Link]
Actually the magic around distribution use of modules baffles me. Bootloader boots, loads a kernel - maybe with an attached initramfs maybe with a separate initrd - executes linuxrc or so from initramfs/initrd, then load a hoard of modules (file systems), probe for some (storage devices), then mount the real rootfs with the new drivers, switch root, run init (systemd) then load even more modules. That intermediate step with a initramfs/initrd isn't really used on anything tailored, can we ever get rid of it, or make it easy for endusers to compile a kernel with her file systems and storage devices already built-in so as to skip this step?
First version of kmod released Posted Dec 16, 2011 1:11 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
if you compile your own kernel with all the drivers built-in you can usually just boot that without any initramfs/initrd
however some distros are making this harder to do (thus the comments from some kernel devs about particular distros being very bad for kernel development because they make it hard to just use a plain kernel)
First version of kmod released Posted Dec 16, 2011 3:20 UTC (Fri) by gsbarbieri (subscriber, #10537) [Link]
Note that although core modules are better to be builtin, eliminating the need for initramfs (filesystem, main system buses, eventually network), you really don't want to have all possible USB and similar by default. God, how many times do you plug in your camera that need special drivers?
Then completely disabling module support is bad, in this case you still have udev looking for modalias and trying to resolve it. If you have it builtin or no drivers it may evaluate to empty list, currently there is no way to know it and udev worker process execute "modprobe -b ALIAS"... It will in turn execute fork, exec, linker, load of multiple index files, lookup and then exit.
With libkmod udev will be able to load the index once and do in-process resolution of alias before doing any action.
First version of kmod released Posted Dec 16, 2011 4:09 UTC (Fri) by nybble41 (subscriber, #55106) [Link]
Even if you don't use modules at all, you may still need an initramfs if user-mode setup is required to access the root filesystem. Examples include root-on-LVM, encrypted root (dm-crypt), and some varieties of network-mounted root filesystems. Any of these options can sensibly be used in a server configuration.
First version of kmod released Posted Dec 16, 2011 4:59 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
most cameras now show up as a mass storage device and so they don't need special drivers.
this didn't use to be the case.
But again, I was saying that servers seldom need modules, how frequently are you plugging random USB devices into servers?
I have been running with module support completely disabled on my servers for many years. I haven't run in to any problems with it.
First version of kmod released Posted Dec 16, 2011 5:43 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
If you know every piece of hardware that will ever be connected to your server then you can certainly build a kernel that will handle it without modules. If you're paying for support from a commercial distribution vendor then you'll probably end up forfeiting a bunch of that support by not running the kernel they provide, but if that's what you want then nobody's going to tell you not to.
First version of kmod released Posted Dec 16, 2011 4:48 UTC (Fri) by josh (subscriber, #17465) [Link]
Distributions which ship compiled packages (as opposed to distributions like Gentoo which build from source) want to ship a minimum number of compiled kernel packages which work for everyone. They don't want to build in every possible driver that might prove necessary to mount the root filesystem, which could include every disk driver, every network driver, every filesystem, every network filesystem, every RAID/LVM/crypto module, and so on. That would make for a huge kernel.
On your individual system, you could certainly build in the drivers needed to mount your root filesystem, though you'll probably still want modules for the myriad USB devices you might choose to plug in. However, you'll need an initramfs if you want any of the following:
- Root filesystem mounted by filesystem UUID or label rather than hardcoded partition name.
First version of kmod released Posted Dec 16, 2011 6:00 UTC (Fri) by rvfh (subscriber, #31018) [Link]
Android kernels also typically have all support built-in, as you would expect for embedded systems in general. Not talking about USB gadgets here of course.
Coming back to libkmod, I think this is long overdue and it's good to see this happening.
First version of kmod released Posted Dec 16, 2011 17:21 UTC (Fri) by iabervon (subscriber, #722) [Link]
I personally find it really handy to be able to unload FAT support and load a version with different NLS junk configured, or unload my wireless driver and load a version build with debugging when my access point does something new and different. (At times, I've had problems where the only way I knew to get my wireless driver to power up the device again was to remove the module so that it forgot it knew about the device, but it's better now.) I've also been glad to be able to patch my hfsplus driver to handle my weird ipod without rebooting. It's also nice to be able to say "no" to drivers for hotpluggable things I may want at some point, knowing I can just build them as modules if I end up wanting them. It's definitely worth having a kernel that will boot without modules, but it's useful to have everything that the system doesn't require (but the users will want) as a module.
First version of kmod released Posted Dec 16, 2011 17:28 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
this sounds like a laptop environment. I'm not disputing the utility of modules there. It's on the server that I'm saying that you are probably better off without them.
First version of kmod released Posted Dec 16, 2011 18:56 UTC (Fri) by iabervon (subscriber, #722) [Link]
On my server, I've still occasionally had the experience of wanting to add a device I didn't originally anticipate needing when I built my kernel. It happens a lot less, and the steady state is 0 modules loaded (and 0 built), but I find it comforting to be able to build and load a module if I need it without rebooting.
First version of kmod released Posted Dec 17, 2011 22:44 UTC (Sat) by nix (subscriber, #2304) [Link]
Quite. It's firewalls and other directly-hostile-Internet-exposed systems on which I enforce a CONFIG_MODULES=n rule.
First version of kmod released Posted Dec 18, 2011 1:05 UTC (Sun) by HelloWorld (guest, #56129) [Link]
The point being? If somebody breaks into your box and gains enough privileges to load a kernel module, he'll also be able to replace the kernel.
kernel modules are a convenience Posted Dec 18, 2011 10:30 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
In fact the somebody can inject a kernel module anyway. The kernel's module enable/ disable is a convenience, not a necessity. Way back when this stuff first happened, and we had the first generation of people saying they're going to disable modules for security reasons, grey hats built POC module injectors which work whether or not modules are "enabled" to show how ludicrous this idea is.
IF you set up the system so that root has far less than traditional privileges and IF you've identified and correctly repaired every hole in the resulting fence between system privileges exercised by the kernel and the privileges of the root user, then maybe you buy some small amount of additional security through disabling kernel modules. But for most people it's equivalent to using a toddler gate as additional security. You may trip up a few babysitters but you won't hamper a burglar.
kernel modules are a convenience Posted Dec 18, 2011 15:53 UTC (Sun) by ranmachan (subscriber, #21283) [Link]
<matrix style>
How do you inject a kernel module... ...if you don't have access to kernel memory? </matrix style>
CONFIG_STRICT_DEVMEM=y
Though you still can just replace the kernel image and reboot into that.
kernel modules are a convenience Posted Dec 18, 2011 18:45 UTC (Sun) by PaXTeam (subscriber, #24616) [Link]
> CONFIG_STRICT_DEVMEM=y
you'd think it does what you think it does but it doesn't... which pill did you take? ;)
kernel modules are a convenience Posted Dec 18, 2011 16:53 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
I think that you underestimate the number of script kiddies out there who don't really know what they are doing.
Along similar lines, an attacker can load any software on the system that they want, so the best practice of not installing anything on servers that you don't need (and especially compilers, sniffers, etc) won't stop a determined attacker.
but in both cases (module loading and installed software), if you can make it harder for an attacker to do stuff on your systems, any attacker who is not out to get you specifically, but is instead just out to get whoever they can will find that their standard tools don't work and are likely to go elsewhere rather than figuring out what they would need to do.
worms and other automated attacks also are unlikely to be able to deal with anything that's non-standard, so anything that you can do to make such tools not work out of the box can be a big win.
Again, if the bad guy is one of the elite hackers and is out to get you specifically (Advanced Persistent Threat is the term used for this nowdays), none of this will help much (although it _may_ slow them down just enough for your IDS to notice), but against the other attacks this helps in the "I don't have to outrun the bear, I just have to outrun you" type of way.
kernel modules are a convenience Posted Dec 19, 2011 1:57 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I would argue that if you are falling to worms or automated attacks that you probably aren't doing anything for security or patching as most automated attacks use low-value, quickly-patched vulnerabilities to spread. IMHO if you have all the basics covered, mangling your OS install isn't going to buy you a whole heck of a lot except for management headaches and you will end up installing those tools (sniffers, etc.) anyway because they are useful.
I would argue that for an APT, no matter how hard you work it won't be enough to keep them out so a strong audit capability to detect unusual activity quickly so you can shut it down and clean it up is a better use of time and resources. Much like how the credit card industry focuses on fraud detection, after transactions have cleared, rather than prevention. Logging and reviewing all sudo logs and other root activity is simple and low overhead and pretty effective.
First version of kmod released Posted Dec 18, 2011 17:12 UTC (Sun) by nix (subscriber, #2304) [Link]
Yeah, but there's no point in making attackers' jobs *easy*.
First version of kmod released Posted Dec 28, 2011 20:56 UTC (Wed) by robbe (guest, #16131) [Link]
Hmm, on netfilter based firewalls, I like the ability to have some seldomly used filter modules lying around, and being able to load them "on demand". I almost never do this, so it is more of a (in?)security blanket.
If we tread into proprietary waters, most Check Point firewalls are based on Linux and load part of their code as a monstrously big kernel module -- making this feature mandatory there.
First version of kmod released Posted Dec 16, 2011 14:45 UTC (Fri) by horras23 (guest, #81864) [Link]
'kmod-lsmod' and 'kmod-modprobe' seem to be a lot slower than 'lsmod' and 'modprobe' when run in a bash loop. Is this due to fact that kmod is new or because I'm a total noob that has no idea what he's doing? :)
First version of kmod released Posted Dec 17, 2011 5:36 UTC (Sat) by cwillu (subscriber, #67268) [Link]
The gains come from not needing to start a new process for each invocation. Running them from bash negates this entirely. The binary itself being slower probably reflects performance tuning in the old modprobe that hasn't been duplicated in the new one, and I believe there was a mention above that there's some additional debugging temporarily enabled to help uncover any lingering problems.
First version of kmod released Posted Dec 18, 2011 18:47 UTC (Sun) by demarchi (subscriber, #67492) [Link]
Well... that is not a fair benchmark. For the one-module case you'll have very similar times with kmod-modprobe and modprobe. There are somethings to note here:
1) The current implementation kmod-modprobe is temporary and only serves so we tune the libkmod API. We'll replace it once we have a more complete API
I'll talk about this in a later post (maybe together with kmod 2).
Again, the focus is not speed, but for the use case of udev it's a nice side effect.
First version of kmod released Posted Dec 18, 2011 21:19 UTC (Sun) by jcm (subscriber, #18262) [Link]
Indeed. It doesn't matter (within reason) how long a single modprobe call on the command line takes so long as the case where there are (potentially) hundreds of calls is reasonable. At this point, most users only experience loading of modules in response to udev handled events, so it's reasonable (now) to focus on udev as the primary user and have a library, and preserve compatible tools for the occasional loading of modules by hand - by a developer, by an admin, or in a few cases where a module is not yet exposing aliases or other means to be loaded automatically on certain platforms. I really like the new library.
First version of kmod released Posted Dec 22, 2011 12:35 UTC (Thu) by jcm (subscriber, #18262) [Link]
Fedora packages are available for early testing (not final or ready for review yet though):
https://lkml.org/lkml/2011/12/22/142
|
|||||||||||||