1 2 next »

Kernel Log: Stable kernels analysed, Linux without firmware, new graphics drivers

Thorsten Leemhuis

The development of Linux 2.6.34 has started and is causing heated discussions on the LKML. LWN.net has analysed Linux 2.6.32.9 for security fixes and found almost twenty of them. Linux-Libre removes proprietary files from the kernel, and new graphics drivers for Radeon cards offer numerous improvements.

A day after the release of Linux 2.6.33 in the last week of February, Linus Torvalds started merging the most important changes for Linux 2.6.34. By last Friday, he had integrated almost five thousand commits, which has added almost two hundred thousand lines of code to the kernel. Among the new additions to the kernel are the drivers for Apple's Magic Mouse, a Python scripting engine for the tracing subsystem, and the vhost_net Virtio server designed to reduce overheads when exchanging data with guest systems via Virtio.

The merge window is still open, although this time it might only last 10 or 12 days instead of the full two weeks – this is what Torvalds indicated to persuade the subsystem maintainers not to wait until the last minute with submitting their changes. However, Torvalds has already criticised a couple of improvements to SquashFS as well as the patches that integrate the subsystem for addressing Ambient Light Sensors (ALS) (1, 2); although they were submitted for 2.6.34, unless Torvalds changes his mind, these two additions are unlikely to make it into the Linux kernel before version 2.6.35.

Torvalds also explicitly reminded the maintainers of the basic driver infrastructure ("driver core") and those of the Direct Rendering Manager (DRM) that new kernel functions should not be enabled by default during kernel configuration unless there is a specific reason to do so (1, 2). As a result, the DRM programmers modified some of the submitted patches, which Torvalds eventually integrated into the main development branch on Thursday night.

It was only in a test shortly afterwards that Torvalds noticed what the DRM subsystem maintainer had already pointed out in his git-pull request: An incompatible API modification to the Nouveau driver for NVIDIA graphics hardware integrated with Linux 2.6.33. Those who wish to use the Nouveau driver for X.org, which is based on the kernel driver, consequently have to update this driver as well as the libdrm at the same time – which makes life harder for other testers and users, as using the Nouveau driver for X.org prevents them from simply switching between the pre-modification and the post-modification kernels.

Torvalds' heavy criticism has sparked sometimes heated and still ongoing discussions in which some of the Nouveau developers point out that Torvalds himself had pushed for a prompt integration even though these and other API modifications were still pending – which is also the reason why the Nouveau driver is still classified as an immature staging driver, as userspace API modifications in fully mature drivers are generally required to be downwards compatible.

Stable Linux

Kernel version 2.6.32.9, which we already mentioned in the previous Kernel Log, is still the latest kernel in the Stable Series. As is the case so often with Stable kernels, the release email for this kernel recommends that users update to the new version without explicitly pointing out any security-related corrections.

However, Jonathan Corbet, the founder of the Linux Weekly News (LWN) and himself a contributor to the Linux kernel, has taken an exemplary look at the 96 changes in a release candidate of 2.6.32.9 and described them in an article on LWN.net which is now also available to non-subscribers. Right at the start, the developer points out that the analysis was a lot of work and that he probably missed a few things.

This proved to be the case, because Corbet had rated 18 of the changes as potential security-related fixes. However, the article's first comment already points out that a further fix would have belonged in this category, as the corresponding hole can be exploited for attacks and even has a CVE number; in further comments, readers speculate about several other, potentially exploitable, corrections that were not rated as security critical.

This demonstrates that simply running the update as suggested in the release email truly is the best idea for the users of self-compiled kernels – such updates are often likely to generate considerably less work than a detailed (and potentially flawed) analysis of the changes. The users of distribution kernels, on the other hand, don't need to worry about this, because in their case the distributor provides the updates – although users have to rely on the distributors to recognise and incorporate the potential security fixes.

Completely free

The Free Software Foundation Latin America (FSFLA) has released Linux-2.6.33-libre. It includes the considerably updated and, therefore, potentially faster libre-kernel de-blob scripts which strip out any Linux 2.6.33 kernel sources the FSFLA considers aren't free; those who don't want to run the scripts themselves can also directly download an archive of 2.6.33 without firmware.

Among the components removed in the Libre kernel are several firmware files that are part of the main development branch of Linux that load various essential device drivers into the chips of their associated devices. The licence of these files allows them to be redistributed together with the Linux kernel; however, since no source code is included such "binary large objects" (blobs) are considered as not free regardless.

As a consequence, some hardware components may not work or may not be fully functional with the Libre kernel and other Linux distributions that don't include these or similar firmware files. This could even affect CPUs, which frequently contain bugs that are fixed or bypassed via "microcode" patches. The motherboard BIOS usually applies such microcode updates before booting the operating system. As many users only rarely update their BIOS, processor vendors years ago already created interfaces that allow the operating system to apply fresh microcode early on in the boot process. This allows CPU bug fixes to be deployed quickly and easily via the update function of modern operating systems. Those who use Linux distributions which don't deploy microcode updates may, therefore, use the processor's older microcode version which might not fix some of the CPU bugs.

Incidentally, the kernel developers associated with David Woodhouse have, for quite some time, been working to remove the sometimes tightly-knit driver and firmware interdependencies. Some distributions have already stopped using the kernel's firmware files and instead include an archive of firmware files maintained by Woodhouse at kernel.org.

Next: New graphics drivers and "In Brief"

1 2 next »