Archive for the ‘Linux kernel’ Category

PCI development project

Sunday, June 1st, 2008

I’m looking to find someone to take over some part-time contract work that I’ve been doing. I’m only stopping as I am about to start some full-time summer work.

The project is Linux driver development for a PCI frame grabber. Kernel experience is essential, and the important areas of knowledge are PCI and DMA. Location does not matter, this is a remote development project.

If you’re interested, or know anyone that might be, please drop me an email.

Lorin Olivier’s GL860 driver

Wednesday, May 28th, 2008

Lorin Olivier has created a kernel driver for his GL860 webcam. Lorin’s device is the 05e3:f191 variant, whereas mine is the more common 05e3:0503. There are differences between the devices that we don’t have much of a grasp on. The code we’ve written for each device is incompatible with the other, even though there are some protocol similarities.

Lorin reports that his driver works reasonably well with his device – it works with camorama, xawtv, ekiga, amsn, mplayer and xsane. He has also determined how to adjust various camera settings (luminosity, saturation, hue, sharpness, retrolighting, mirror effects, light source, AC power frequency).

Although Lorin doesn’t actually own an 0503 device, he’s attempted to implement support for it based on my earlier efforts. Given that I didn’t get very far, it probably doesn’t work that well. I haven’t had a chance to try it, but there’s no point me sitting on this any longer.

It’s in my git repository in the nvgl subdirectory:
git://projects.reactivated.net/~dsd/gl860.git (gitweb).

All credit goes to Lorin here – thanks! He’s done a great job, but do remember that its experimental code based on a reverse-engineered protocol, so don’t expect it to be flawless.

Critical Linux kernel vmsplice security issues

Monday, February 11th, 2008

There have been 2 significant security flaws found in the Linux kernel, accompanied by plenty of misinformation and confusion. This is my attempt to clear things up a bit.

The short story: If you are running Linux 2.6.17 or newer then any user who has local console or SSH terminal access to your machine can easily become root or crash the system. If this is a problem for you, then you need to upgrade to gentoo-sources-2.6.23-r8 or gentoo-sources-2.6.24-r2. At the time of writing, there are no official released upstream kernels which solve the issues – Linux 2.6.24.1 and 2.6.23.15 are vulnerable.

The longer story:

There are actually two separate security issues in question here. However, they both have the same impact (any user can adjust kernel memory and hence become root), and both issues exist within the implementation of the vmsplice() system call. vmsplice() was added in Linux 2.6.17 and is built into every kernel build – there is no configuration option to exclude vmsplice. Two separate exploits have been publicly released which exploit each of the two issues respectively.

The first security issue under discussion was added in Linux 2.6.23 (obviously unintentionally!). This means that 2.6.22 and older are not vulnerable to the first exploit. This issue was fixed by this patch in Linux 2.6.23.15 and Linux 2.6.24.1. This vulnerability has been classified with two codes: CVE-2008-0009 and CVE-2008-0010.

The second security issue is more serious. Firstly, it has existed for the entire lifetime of vmsplice() which means that any kernel version 2.6.17 or newer is vulnerable. Secondly, it is not fixed in any upstream kernel release at time of writing, but the fix has been merged into Linus’ upstream development tree. This vulnerability has been assigned ID CVE-2008-0600.

gentoo-sources-2.6.23-r7 and gentoo-sources-2.6.24-r1 include the fix for the first issue, but are still vulnerable to the second (which is equally serious).

gentoo-sources-2.6.23-r8 and gentoo-sources-2.6.24-r2 include the fix for the second issue and are hence secured against all known vmsplice exploits at this point in time. 2.6.23-r8 will be marked stable when I wake up 7-8 hours from now, so testing of that release would be appreciated.

UPDATE: gentoo-sources-2.6.23-r8 is now stable, and upstream have also released the following which fix all currently known issues: Linux 2.6.23.16, 2.6.24.2 and 2.6.25-rc1.

Gentoo kernel project contributors

Friday, January 18th, 2008

On the Gentoo kernel maintenance front, I’ve been slacking lately. After launching the project, my fingerprint scanning efforts soon started to eat almost all of the time I’m willing to spend in front of a computer. Then comes a busy xmas/new year, quick week in the US, exam revision and now exams; it’s been a few months since I put proper time into the Gentoo kernel front. I’m feeling a little guilty as this inactivity all started at pretty much the same time as when I became the kernel project lead.

Yet, the Gentoo kernel bug list shows only 23 bugs open, plus no critical/widespread unsolved issues at a cursory glance (when I was doing this singlehandedly, I usually had problems keeping this count below 40). This is all thanks to Maarten Bressers, Duane Griffin and Mike Pagano. Unfortunately Maarten is tied up with other issues at the moment, but Duane pops up from time to time and singlehandedly solves some tricky-looking issues and Mike is very active and is doing a fine job keeping things shipshape.

Before getting involved with Gentoo kernel bugs and genpatches maintenance, all 3 of the aforementioned people had no prior involvement with the kernel. One of the things that prompted me to write this post was to get up today and see an IRC conversation, where Mike uses some diagnostic knowledge he’s gained from a Gentoo kernel bug to make a suggestion to another user who is having trouble booting their system (which I am quite confident will solve the issue). Definitive proof that Mike has become a skilled and efficient bug-attacking machine.

If other developers are wondering how I managed to recruit these “newbies” into enthusiastic and productive contributors, my process was as follows:

  1. Write a maintenance guide giving people enough information to get started
  2. Encourage the interested respondents to ask lots of questions (I think this is the most important part — be clear that you’re available to be consulted).
  3. Advertise it in the Gentoo Weekly Newsletter.
  4. Wait for some questions to come in (and answer them).

All in all, it was quite time consuming to write the initial document and then answering questions, but the fact that I can then be largely inactive for a few months and still have things running smoothly tells me that it was worth the investment.

Recent ramblings

Friday, December 28th, 2007

Recent writing-related updates:

gentoo-sources-2.6.23 feature changes

Tuesday, October 9th, 2007

Linux 2.6.23 was released a few hours ago. See the kernelnewbies changelog lots of details.

In addition to all the upstream changes, gentoo-sources-2.6.23 (which will be in portage very soon) has some Gentoo-specific feature changes worth noting:

vesafb-tng replaced with uvesafb

Michal is the author of vesafb-tng, which is popular as it allows you to use higher frequency refresh rates on the VESA framebuffer to stop you getting headaches on CRT monitors.

Michal has always been first to admit that vesafb-tng was an ugly hack and has no future. He’s now able to refrain from insulting his own coding abilities though, as he has reimplemented the functionality in a way that isn’t an ugly hack.

uvesafb is the replacement. The fundamental difference is that much of the functionality has been moved out of the kernel into userspace, so the kernel doesn’t have to worry about the ugly details.

The big change on the inside means that it’s unfortunately not a direct switchover to uvesafb from vesafb-tng. There are installation instructions on the uvesafb project homepage.

In fact, the uvesafb code is so non-ugly that it has been accepted into the upstream Linux kernel for the 2.6.24 release. Thanks Michal!

fbsplash replaced by fbcondecor

Michal also authored fbsplash, a kernel patch to allow you to place a pretty splash image behind the framebuffer console.

Due to confusion in the naming, fbsplash has been renamed to fbcondecor (FrameBuffer CONsole DECORations). However, this is just a simple rename, so the migration path is not difficult. See Michal’s blog for further details.

speakup isn’t back yet

speakup is an in-kernel speech synthesizer for blind/hard-of-sight Linux users.

We dropped speakup for 2.6.22 as it was no longer compatible with the kernel. I was planning to revive it for 2.6.23 but I haven’t had time, so it will have to wait for 2.6.24.

New hardware support in the Gentoo kernel

Saturday, July 21st, 2007

Just a quick reminder regarding the gentoo-sources patching policy:

If you have some new hardware which is currently not supported by gentoo-sources, but you know of drivers or patches in the upstream development kernel to support such hardware, you are encouraged to file a bug and we will consider backporting the patch to the current release kernels.

An ideal bug report would look something like:

I recently purchased a Fritzomatic E2 which is not supported by the current gentoo-sources (tested both stable and testing). However, the upstream 2.6.23-rc kernel tree does contain a patch to support this hardware. I applied this patch to 2.6.22 and it works great. Here’s a link to the patch: http://foo. Please consider for upcoming gentoo-sources releases.

Even if you aren’t able to initially go into such detail, you should file a bug anyway.

While we won’t proactively go out adding new hardware support to kernels, if such patches are requested and tested by Gentoo users, we’ll add them provided that they don’t show immediate risk of increased maintenance burden.

ZD1211 back in production

Thursday, May 24th, 2007

Since the Atheros acquisition, introduction of new ZyDAS ZD1211 USB-wireless devices has been concerningly slow.

Fortunately, some new ZD1211 devices have been popping up recently, based on new radio chips. After some help from the community, I managed to get my hands on the new types and write zd1211rw code needed to support these chips.

The first new chip, the AL2230S, only needed a few changes on top of the older AL2230 code. This radio is working well.

The second new chip is especially interesting: the Ubec UW2453. Ubec publish full technical specs for this chip, so we’re able to understand more than usual about the ZD1211 interactions with the radio. Maybe due to it’s complexity, the UW2453 isn’t performing quite as well as the other radios, but this should improve after time. I emailed ZyDAS some feedback about their UW2453 programming code – I think I spotted a few mistakes.

Third, we started seeing the already-supported AL7230B RF chip being combined with the ZD1211B base chip on some newer ZyXEL products. This particular combination was not supported before, but thanks to some testers on the mailing lists, the code has been written and submitted to support these.

Fourth, Atheros appear to have rebranded the ZD1211B chip as AR5007UG. These devices are appearing in Medion laptops, very popular in some parts of Europe. The first ones seem to be based on the UW2453 RF mentioned above. I’m especially interested to hear from people who have AR5007UG devices in other laptops or in standalone USB-dongle form, and also if they exist based on other RF chips.

All the above will be available in Linux 2.6.22, except UW2453/AR5007UG which will be available in 2.6.23.

On a final note, I moved the zd1211rw homepage to the new linuxwireless.org wiki. One nice feature here is that the zd1211rw supported devices list gets aggregated onto the more general Linux-supported USB wireless devices list, however we’re the only USB driver with device information published there at the moment.

Using ketchup to quickly install kernel sources

Monday, April 16th, 2007

ketchup is a neat utility to download and unpack a specific version of the Linux kernel sources into the current directory. It also does rather well on saving download bandwidth, i.e. if you have the 2.6.17 source tarball and ask for 2.6.18, it will only download the 2.6.17-to-2.6.18 patch.

Here’s a quick usage example, which installs the 2.6.21-rc7 kernel sources:

# emerge ketchup
# cd /usr/src
# mkdir linux-2.6.21-rc7
# cd linux-2.6.21-rc7
# ketchup 2.6.21-rc7

When ketchup has finished, you then have a clean set of kernel sources for that particular version in front of you.

I like to configure ketchup to use the same storage directory as portage, so that they can share kernel tarballs. In my ~/.ketchuprc I have:

archive = "/usr/portage/distfiles"

Wireless Summit II

Thursday, February 1st, 2007

Earlier this month, I met with 25 other contributors at the 2nd Linux Wireless Summit. This was a followup from the 2006 summit.

The meeting happened in London and was scheduled to occur immediately after the IEEE 802.11 working group meeting. This enabled us to get some kind of vendor attendance.

While we had this opportunity, one of the biggest topics was discussion of why vendors still aren’t playing nice in releasing open source drivers (or providing the resources to let the community do so). The vendors in the room confirmed our suspicions – vendors are afraid of the FCC and other regulatory agencies who place restrictions on frequencies and power levels which these devices are legally allowed to transmit as.

Matt Norwood from the Software Freedom Law Center was in attendance and had studied the FCC regulations in some detail. The conclusion is that the FCC rules are vague and while they don’t explicitly say that open source drivers are not allowed, vendors are not prepared to risk falling out of compliance and are playing it safe (or not playing at all). Unfortunately there is no short term solution to this: it would take years for the FCC to clarify the regulations. Short term workarounds such as finding ways to encourage vendors to produce open drivers with only the regulatory part closed (such as Intel’s ipw3945 offering) are under investigation.

The other large topic was the merge of the new wireless stack (d80211) which was donated to the community by Devicescape. The stack has many more features than the current in-kernel ieee80211/softmac stack, and improves consistency between drivers. We are now much closer to getting d80211 merged into mainline Linux, but there are still some significant technical issues to be resolved.

Before the conference, several people asked me if I could raise issues with the suckiness of Intel’s ipw3945 driver offering in that it relies on this awkward closed-source userspace daemon. Fortunately Intel have found a way to rewrite their firmware so that the regulatory domain control is no longer at the driver level, therefore a fully open-source driver with no binary userspace part has been developed (iwlwifi). Although Intel have not yet announced it, the source code has been released here. This rewritten driver uses the d80211 stack mentioned above, so it’s not possible just to compile it against mainline Linux at the moment. The iwlwifi website includes instructions for how to check out the wireless-dev tree where d80211 is being held.

All slides and notes from the conference can be found here. Stephen Hemminger wrote a more detailed summary. Also, one other significant product of the summit was a central information source aimed at Linux wireless users – we have now launched linuxwireless.org.