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.
I’ve been a bit quiet on on the fingerprint scanning front recently, but I’ve been doing a lot of work behind the scenes.
Adopted the libusb project
libfprint has had a design flaw from early on: it only provides a synchronous interface. The technical minded will understand this better in terms that each function call to scan a fingerprint blocks for the duration it takes the user to scan their finger. The library could force its users to do fingerprint scanning in a dedicated thread, but that’s not very nice. It could also create threads internally to avoid this problem, but I don’t agree with that either. I know that things can be done properly by providing an asynchronous interface and not requiring any threads.
The biggest roadblock in offering an asynchronous interface from libfprint (and the reason this was not offered from the start) was due to libfprint’s reliance on libusb and the fact that libusb does not offer asynchronous I/O. The result of this is that it is impossible to offer true asynchronous functionality in anything built on top of libusb.
libusb development had unfortunately stalled, and I could not find any alternatives that I was in agreement with. I started writing my own libusb replacement. The original libusb author, Johannes Erdfelt, liked my ideas and this lead to him handing off the libusb project to me. My new USB library will be released as libusb-1.0 when completed.
Making fprint asynchronous
After producing a working prototype of an asynchronous USB library, I converted most fprint drivers to an asynchronous model and exposed an asynchronous API to library users.
I then ported fprint_demo to use the new asynchronous API, which is working well. Another big plus of an asynchronous model is the opportunity to implement cancellation. fprint_demo now has a working “cancel” button which cancels any ongoing fingerprint scan request.
Exposing fprint over D-Bus
Next task on the table was to work towards handling the complicated scenario of when multiple users and/or applications want to be fingerprint scanning simultaneously. Some kind of central entity is needed to coordinate access.
Enter fprintd, my initial step in this direction. fprintd is a D-Bus daemon which exposes fprint functionality over the D-Bus message bus. There are no fprintd users yet, but this will be the approach we take for desktop integration in future.
Assessed project demo
As I mentioned previously, fprint is actually my final year university project and after reaching the stages described above it was time for an assessed demonstration of my project.
The demonstration went extremely well, and I was impressed with the marker who asked exactly the same kinds of questions that I would have done in that situation – which of course I knew the answers to. He also understood the asynchronous issues perfectly despite me not explaining them in detail due to time constraints.
What next?
The above development work was all a little rushed in order to have things to show in time for the project demonstration. Now that the demo is over, I am left with an incomplete libusb-1.0 implementation, an unstable libfprint asynchronous API, a new fprint_demo version relying on the unstable API, and an unstable/incomplete D-Bus daemon. All of these are not released (but code is available from public development repositories) so I have some work to do!
I am going to focus now on stabilising from the ground up, starting with the most low-level component – libusb. I’m working through the TODO list and hope to have an alpha or beta release ready within the next few weeks.
I’ll be at FOSDEM this weekend. Please say hello if you find me.
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.
I remember playing a DOS game on my 386 computer, probably when I was about 10 years old. The game presented an unlabeled map of Europe on-screen, then proceeded to ask me to click on Portugal, Germany, Switzerland and all the other countries in a different order each time you played the game.
The game kept track of my high scores in terms of both the number of countries I got right/wrong, and also the time it took me to identify them all. I played this repeatedly, trying to beat my own records. I learned a lot about European geography this way, and it was fun. It’s similar to this online game except the game I’m thinking of had metrics to keep track of your performance and highlighted the right answer whenever you clicked on the wrong country.
This is a great example of hard fun, one of the principles of educational constructionism behind the OLPC project. As such, I’m considering writing a clone of the game for the XO laptop.
I’d love to dig out the old DOS game again, but I can’t remember what it was called! Does anyone else know of its name, or have any recollection of this game?
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.
I’ve been back in Boston this week, and I spent some time visiting the OLPC offices in Cambridge. People aren’t joking when they talk about laptops hanging from the ceiling.
Formal testing is a big thing at the moment, so I spent some time helping out testing the upcoming release branches. I also sneaked in a few bug fixes here and there, and managed to solve some irritating interface quirks.
This was my first interaction with the laptops, and I must say, those little XO machines are incredible. I’m overly impressed on all accounts, especially with the vast level of improvement of the currently-being-finished Update.1 software release over the current stable Ship2 release. There are a number of great people there, from an interesting variety of origins – mirroring the multicultural aims of the organisation, I suppose. Many thanks to those who helped me fit in and get started.
Recent writing-related updates: