Kernel and proprietary drivers

The problem of the use of proprietary closed source drivers is a very important subject in those 2006 days.

openSUSE decided to follow the kernels developpers recommendations. Here are some documents to clarify the problem.

The original source

To understand the case, the best way if to look at the linux-kernel mailing list.

One example

The original

Here is the original of the post copied below, for reference purpose.

http://marc.theaimsgroup.com/?l=linux-kernel&m=113378006232564&w=2

This post is copied to the wiki in the only purpose of making it easier to read.

The example text

The post linked upper is copied here. It's just edited to cope with the wiki syntax.

This is hypotetical. The way the distros named in the text act is also hypotetical and only like imaginated by the author.

List: linux-kernel Subject: Linux in a binary world... a doomsday scenario From: Arjan van de Ven <arjan () infradead ! org> Date: 2005-12-05 10:52:32 Message-ID: 1133779953.9356.9.camel () laptopd505 ! fenrus ! org [Download message RAW]

Linux in a binary world

What if.. what if the linux kernel developers tomorrow accept that binary modules are OK and are essential for the progress of linux.

a hypothetical doomsday scenario by Arjan van de Ven

the primary assumption in this scenario is obviously not going to happen, but all assumptions that follow are based things that are true in some form or another, but of course the names of the "innocent" have been omitted.

On December 6th, 2005 the kernel developers en mass decide that binary modules are legally fine and also essential for the progress of linux, and are as such a desirable thing. At first, the development process of the linux kernel doesn't change much other than a bunch more symbols getting exported, and EXPORT_SYMBOL_GPL removed.

Within 3 weeks, distributions like Red Hat Enterprise Linux and SuSE's SLES distribution start to include a wide variety of binary modules on their installation CDs. Debian renounces this and stays pure to the cause, as do other open distributions like Fedora Core and openSuSE.

The enterprise distros don't just NVidias and ATIs modules, but include all the OEM vendor "fakeraid" modules and the various wireless, winmodem, windsl and TCP-offloading modules as well,. However, unlike NVidia and ATI, most of the binary driver vendors do not provide their drivers in a "glue layer" source form, they provide only the final binaries.

Several hardware vendors that have been friendly to open source so far, see their competitors ship only binary drivers, and internally they start to see pressure to also keep the IP private, and they know that they haven't used some features of the hardware because their legal department didn't want that IP in the public. As a result they perceive their competitors binary drivers to be at a theoretical advantage, or at least their own drivers could be at an advantage if they were also closed, because they then can use those few extra features to be ahead of the competition. By February 1st 2006, about half the hardware vendors have refocused their internal linux driver efforts to create value adds in the binary drivers they will release in addition to the open drivers that already exist. Some vendors even openly stopped supporting the open drivers because they don't have enough resources to do both.

March 1st. All the new server lines from the top tier hardware vendors come out with the next generation storage and network hardware. This hardware comes with binary drivers for the last 2 versions of RHEL and SLES distributions, and these drivers are already integrated into the February refreshes of these distributions. One of the storage vendors releases their driver in a .o + glue layer format, the others doesn't bother and only releases binaries for these two distributions. Two of the network card manufacturers release an update for their open source driver to minimally support the new cards, the others don't. Consumer hardware is largely unaffected; most consumer chipsets standardize on AHCI for SATA storage and keep the existing feature sets in networking chipsets.

April 1st. 2 of the consumer chipset makers have upgraded their chipsets to include a new and exciting audio feature that enables enhanced DVD playback, but unfortunately this caused them to deviate from the 'standard' i810 audio hardware interface. One of them releases a binary driver for a handful of distributions, the other doesn't consider linux relevant for the desktop and hasn't bothered to do a linux driver yet.

May 1st All of the server class hardware you can buy requires at least one but usually 2 or 3 binary modules to operate. While some of these modules are available in blob+glue form, several are only available for RHEL3, RHEL4 and SLES9 and sometimes the newly released SLES10. Linux users will have the choice of 4 kernels for these servers at this time, but no hope to run a kernel.org kernel on these servers. The Ubuntu people are very upset and are trying hard, with varying success, to get drivers available for their distribution. Due to this lobby success, about 50% of the servers can be used with the Ubuntu kernel as well.

June 1st. A huge flamewar, the fourth on this topic since January, happens on the linux-kernel mailing list. Users and some developers are demanding that the kernel.org kernel adopts either the existing RHEL or the SLES module ABI. Investigation shows that this is not possible, and the thread turns into a discussion on designing a new ABI versus freezing the existing one. Many kernel developers feel that the existing ad-hoc ABI is not suitable for freezing and that a new ABI and API, designed such that it can be kept stable more easily is the way to go, while others say that this takes too much time and then won't help for the next 2 years until RHEL and SLES have adopted this ABI, and at least demand an immediate freeze of the kernel.org ABI so that the upcoming RHEL5 release maybe uses it, and thus gets drivers written for it. Users generally use RHEL or SLES for production servers, and clones like CENTOS which have released binary compatible kernels.

July 1st. It's increasingly hard to run linux without binary modules on most new consumer PCs. While a year earlier people would have to give up 3D acceleration for this often, now even 2D doesn't work without binary drivers, nor does networking (both fixed wire or wireless) or sound. For half the machines there is not enough linux support available at all, while 20% use ndiswrapper like translation layers to run the Windows sound and networking drivers. The Debian project, unable to run on most machines now, is losing massive amounts of users to Ubuntu and Ubuntu-Debian hybrids. Debian-legal and various other project lists are impossible to read by people not interested in this particular flame-topic. Most of the vendors who kept their open source drivers at least somewhat updated have basically stopped doing so.

July 14th. Linus declares the kernel ABI stable but also splits off a 2.7 kernel and declares that the 2.8 kernel will have a different ABI. In practice, only people who held on to their old machines can assist in the 2.7 development, since none of the vendor drivers, not even the ones who still have a blob+glue construct care about the 'too rapid' moving development tree.

August 21st. A serious security flaw is found in the 2.6 series, which turns out to be a design flaw in a key sysfs API. Fixing this flaw would require to break the module ABI and practically all modules out there, while not fixing this flaw leaves a potential roothole open. A quick fix is made available under a CONFIG_ option, but users who need binary drivers have no choice but leave their systems vulnerable. Flamewars on lkml flare up again that say Linus made a mistake in freezing the existing ABI rather than creating a new one designed to be frozen. 2.7 development has mostly stagnated and a patch is proposed to have 2.7 have the 2.6 ABI again, reverting several key VM subsystem improvements and Ingo's realtime patches.

August 26th. A precooked exploit for the security hole hits bugtraq, and has been sighted in the wild as used by various rootkits. A php exploit uses it to go from the httpd user to root. Users are putting pressure on module vendors to release modules for the new ABI, and several actually do so in the next three weeks. Others, mostly in the consumer area, say that the hardware in question is no longer sold and that they aren't going to spend any time or effort on drivers for it.

Now this scenario may sound unlikely to you. And thankfully the main assumption (the December 6th event) is extremely unlikely.

However, and this unfortunately, several of the other "leaps" aren't that unlikely. In fact, some of these results are likely to happen regardless; witness the flamewars on lkml about breaking module API/ABI. Witness the ndiswrapper effect of vendors now saying "we support linux because ndiswrapper can use our windows driver". I hope they won't happen. Some of that hope will be idle hope, but I believe that the advantages of freedom in the end are strong enough to overcome the counter forces.