Driver On demand is a driver management system designed for Linux, designed to automatically install drivers by using a httpd server. Its other intention is to create a universal driver standard for Linux, allowing drivers to be installed easier.
The first automatic driver installation system for Linux
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
These are the kind of projects I would be more than willing to donate towards. Anything that moves forward towards unification in Linux gets my support!
Great work!
– j
Know we just need a better install system to be included in all distros.
well then take a look at autopackage that there was some news about not to long ago. then there are project utopia to that will act somewhat like this system by makeing easyer to write a driver for linux…
I’m wondering if this system will actually allow you to easily distribute 3rd party drivers in binary form, ie by defeating modversions somehow. I read the website but it doesn’t seem to tackle this issue anywhere. What is the point in contacting a remote server if you only get told to upgrade your kernel?
In other words, will .driverinstall files actually point to binaries you can download, load into the kernel and start using your hardware with (which imho is the biggest problem), or will it not?
Driver management is the biggest sore spot for linux. Applications are generally very good, especially for how much you pay.
if they can actually pull it off.
after viewing the page again, it says that they’re only going to use GPL software. here’s a quote
“Open source, GPL.. Which means u dont need to worry about licensing”
I’m not too worried about it since the only driver i’d CONSIDER using would be the nvidia driver.
Aside from relying on a centralized driver listings server on the internet, how is this different from say, kudzu? Does it aim to provide binary drivers that are compatible across multiple kernel versions? How will it solve the symbol problems? What about graphics devices? Will it be able to reliably modify the X configuration files?
It’s very sketchy on specifics. I’m skeptic this person really knows what they’re doing.
Why invent the wheel again? They are already working on some kind of driver loader. It’s called HAL (Hardware Actraction Layer). Or am i wrong? I think that has muc more feature.
somebody should contact the HAL maintainer and the maintainer of this project, maybe they can work together? maybe they don’t know about each other? maybe they already decided they are better than each other?
who knows
“(Hardware Actraction Layer)”
(Hardware Abstraction Layer)
after viewing the page again, it says that they’re only going to use GPL software. here’s a quote
“Open source, GPL.. Which means u dont need to worry about licensing”
Rob, please. That’s either an inaccurate quote or widely interpretable: do they mean the software they are using, and how are they making it impossible to support proprietary modules? or, do they mean the license of their software itself? From what i read what you quote, i’d say the latter is more likely, and more reasonable.
I don’t know if HAL is the same or wether it is finished. Just in case someone wants to learn more, HAL’s website is http://hal.freedesktop.org
Does anyone else see the horrible security issues with such as thing? I mean if this site gets hacked and someone inserts a worm into these drivers which half the world downloads we are into serious problems. Unless the security issue is solved this project is going to be a severe danger to the strong security reputation of Linux.
One way to solve this might be to run device drivers outside the kernel where they will do less harm.
Sorry, but if this takes off, it’s going to be the worst thing for security.
Damn it, I wish people would stop trying to Windows-ize Linux with these stupid gimmicks. All it’s going to do is attract people to Linux that are irresposible with their Windows computers already (ie. the wormy).
At the moment, there is NOTHING stopping people doing stupid things like uploading infected RPM’s to rpmfind.net.. Driver on Demand has digital signatures, which by default (well, not in alpha 1 because the config file isn’t set to do it), can be set to be required for a driver.. These are only given out to vendors, and the server owner, and people are allowed to choose if they want to require a digitally signed driver, or not.. This means that compromised files for driverondemand will only work if the keyservers are hacked too, or the vendor/server admin is an idiot and leaves his private key lying around for anyone to see (which is why I recommended saving it directly to flashdisk).
Users also have the ability to use their distro’s own package system, which means if your running gentoo, if theres a package for portage, it will use that instead of native commands (its set to use distro specific packages by preference). So, if your package repository is secure, then you’ll be fine.
To solve the worm problem, alpha 3 will use a sandboxing system hopefully, not only for administrators (for them to just click the submitted files before adding them to the database), but also for users, by using User mode linux, or some other kind of VM system to prevent the rm -rf / problem.. In the admins case, the vm will contain forensic commands etc to allow them to check if theres a worm/trojan attached, and do other forensics.. Despite the impression given, drivers will only be added to the database after the driver on demand server owner decides they should.
The funny thing is that at the moment the system is 100% secure guarenteed.. How do I know that? The submission script isn’t working on the sourceforge server because of permission problems, meaning theres not one device definition on the server at the moment.. Which is why when you run it, it says no drivers found or everything (in debug mode, in normal mode nothing is shown)..
And yes, I am going to try to contact the programmers of HAL today and project utopia, so maybe we can collaborate a bit and get some interaction happening (maybe even develop some shared scripts)..
The worst that can happen with this system is that:
– The driver database is hacked and some people with the allowinsecure flag suffer a grisly death.. And the server admin doesn’t set his key to compromised (There will be controls put in place to distribute server keys over the keyservers too). I have also thought about implementing the ability to store them on systems like freenet, which distribute it securely.
– The keyserver is hacked and people think all their keys have been compromised
– A vendor key/server key is hacked, which is alot harder to do then now. At the moment they hack a server with your drivers, and, your screwed.
None of these things will worry you however if you use package management only, unless you have packages of trojans in your distribution (I am only thinking about including packages for APT, or portage or similar repository based systems though).
Alpha 1 of course doesn’t have all the security systems in place. I am aware of a few security problems with it, which will be fixed on the new few alphas.
Overall, dont include this with any distro just yet.. unless you use your own servers and set it by default to use your packages only.
And I know people dont like Linux becoming a bit like Windows (because even I like hard stuff), but we have to accept that we do need a system like this eventually.. Large corporate systems for instance could save alot of time when theres lots of configurations..
Dont worry about the worm thing though.. I am doing my best to ensure that wont be easily done, in fact, even with alpha 1 its possible to set up a system that is secure, but I DONT recommend relying on that at the moment.. while this works and is maybe good for a play, its definately not what I’d call deployment worthy. Just believe me when I say that I am working on mechanisms designed to boost security of driverondemand dramatically (that was another reason I used perl too instead of C++.. no buffer overflows).
Read the security.txt included on some of the various mechanisms to provide security..
After reading the project website, I don’t see where this has any benefit. It’s just a centralised database, which is cool. But client side, it should be handled by HAL — and should use the same file format for describing drivers. Downloading drivers over the net is pointless, because the kernel doesn’t have a binary interface, so the odds of getting a driver for your kernel are slim.
The other option is to promote user-space drivers. These work similar to microkernel drivers – which are just user-space programs that get access to the hardware. If you can expose enough of the kernel interface to user-land, then you can write drivers for user-space. This has already been done before of course: lufs.sourceforge.net, DriverLoader and ndiswrapper being examples (the latter two running *windows* drivers in userspace). The benefits are:
– easier debugging : can run the driver under gdb, restart the driver, less reboots.
– difficult to crash the kernel : driver runs in a seperate memory space to the kernel – just like a user program.
– installing a proprietary driver or non-proprietary but pre-compiled driver becomes as trivial as installing a pre-compiled program.
– The driver works across kernel versions.
Cons:
– slightly longer latency because of the transitions between userspace and kernelspace.
This was discussed at linux.conf.au 2004:
http://www.linux.org.au/conf/2004/abstracts.html#24
Driver on demand does NOT provide a new format of drivers/binaries, the files I proposed (which will be completely changed for alpha 2 anyway), are just wrappers, which they include with another driver (. The purpose of HAL and driver on demand are also completely different.
I might be wrong, but from my understandings, HAL needs drivers available before it can use the devices. My intentions are only to provide minimal configuration of the devices at this time, and from my understanding, if theres no driver for the device, HAL will do nothing, because it cant.
Basically, HAL knows what the purpose of each device is and offer a common way to access them. Driver On demand has no idea.. nor does it need to. The driver format I use is just a wrapper around a tar.gz, or something else, and is not meant to replace them.
-Driver on demand looks up and installs drivers which aren’t installed on the system..
-HAL provides a easy way to access drivers which are already installed..
The driver format I use is mainly just for the database so it knows what to get.. I believe that in the future Driver On Demand might have to send signals to HAL so it knows that a new driver was just installed (that didn’t exist before), and so it can record it etc (pretty much minimal interaction, which is done with hotplug already).
I am trying to contact the project utopia/HAL/Hotplug people at the moment to see where my project fits into it, and whether it overlaps with anything, and whether there are any specific components it should interact with. I will however find out whether there are any better way to database the drivers then using my wrapper files
And I do agree with you, User space drivers are great.. And in fact, systems like driverloader can benefit off Driver on demand too (in fact, they are the systems that benefit most). Because if a driver isn’t found, Driver on demand finds an appropriate User space driver, installs it and modprobes it.. And userspace drivers could actually help reduce possible security problems too with this, and make it more reliable..
Like I said, this isn’t a library or anything to define a specific Driver format.. The driver source etc is not digitally signed, the only thing signed is the wrapper files which contain a list of drivers for a device.
Thanks for the suggestions, but maybe I need to add to the Frequently asked questions, because I think I may not have explained things well.. Because I have noticed a lot of people are misunderstanding it
A simple use case for this is (to clarify things is):
1) hotplug determines a device has been plugged in
2) hotplug tries to load a driver, and only if it fails, it loads Driver On Demand.
3) Driver On Demand looks at the device that has no driver, and fetches a list of possible drivers online (a .linuxdriver file).
4) Driver On Demand might go “hmm, well, the user loves LUFS, so lets see if we have a LUFS userspace driver on the list”
5) If They dont have LUFS, it might check for other types of specialised drivers (like driverloader ones or others, or normal ones).
6) Driver On demand determines the drivers the user most wants, and reorders them by order of preference.. It also wipes out the choices the user doesn’t want (like ones which aren’t signed, or are signed wrong, or wrong arch, poor success rate, not a LUFS driver, doesn’t have a package for ur distribution), etc.
7) Driver on demand installs (needs to download the file normally and most the time compile it automatically) and modprobes/runs the module… if it fails, go to the next preferred driver on the list to try..
8) If driver was successfully inserted, send a signal to HAL, or whatever other systems available to manage the driver (deal with specifics)..
In the perfect world.. HAL and other layers would work out that the device suddenly started working because they got a driver by themselves, but if they dont, we have to tell them to recheck for newly added drivers..
In an even better world, all the drivers for every device get included with every distro, but this overcomes that shortcoming
Hopefully this solves a few questions about the exact purpose of Driver On Demand, and its easier for people to tell if it sucks or not.. Hopefully it will give pinky and the brain more time for world domination, instead of having to find their drivers
“Cons:
– slightly longer latency because of the transitions between userspace and kernelspace.
”
Considering how anal some gamers are about frame rates. That may be a bigger con than you think. The rest looks nice.
I use Mandrake as my distro of choice.. I get all my software and updates from servers.. Lets face it nothing is 100% secure, even Windows Update is subject to security problems (site hacks, etc.) Anybody who uses any comtemporary OS gets SOMETHING from the net, you just have to choose sites that are well known – and yes, you just are going to have to use some trust..
This whole anti-site integration is a bunch of hogwash, if it makes it easier to use Linux and the sites are ‘trusted’ I really don’t see a problem with the whole idea. There’s a whole lot of gripping out there about new/’new’ ideas being put into motion but few solutions.. If you don’t like the direction that things are heading, don’t moan about it, sit your duff down and come up with a better mouse trap..
~