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 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.
Lorin Olivier also has a GL860 with a different USB ID (05e3:f191) in an Asus F5RL laptop. He had some success with my code but the images look to be in a different format when running my software. He’s contributed traffic logs from windows which I’ve put alongside mine in the git repository.
Simon (Sur3) also tried it with his 05e3:0503 device and got a seemingly different image format as well. He also took an image that came back from mine and decoded the Bayer colour space, so I can now get images back in colour!
It’s great to see other people getting involved in these efforts, as I will probably not be able to put much time towards this for a while.
More webcam hacking. I can get proper images now, minus colour. I’ve published my code: git://projects.reactivated.net/~dsd/gl860.git (gitweb interface). Nightly snapshots will be generated here.
So far it just includes my experimental programs to try and make sense of the protocol and capture images. It works, sort of, but there’s a lot to be done. It also requires libusb-1.0 due to the isochronous endpoint. Only try it if you’re interested in development or are just very keen and curious.
I’ve been hacking on the webcam in my System76 laptop. Here’s what I can get under Linux:
There seems to be an element of software-handled synchronization I have yet to understand. And who needs colour anyway?
Although I’m not really working on the “old” code any more, I released libfprint v0.0.6 today. It fixes compatibility with newer DigitalPersona scanners including the ones in Covadis products (who kindly donated hardware to allow for this development). It also adds Gustavo Chain’s driver for the SecuGen Hamster III.
Gavin Smalley donated a Veridicom 5thSense scanner, which I reverse engineered and produced a driver for. This driver is only available from the highly volatile libfprint development repository. It works well.
System76 generously donated a laptop with one of the dreaded 147e:2016 UPEK scanners so that I can work on getting it supported in fprint. It’s too early to discuss driver practicalities, but I have almost figured out the image format.
The laptop also includes an integrated Genesys Logic GL860 USB webcam (05e3:0503), not standards compliant and not usable under Linux. I’ll probably also be working on a driver for this device. Again, I have already almost determined the image format, but have not looked at the rest of the traffic.
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.
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:
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 writing-related updates:
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.