Tuesday, August 19, 2008

Linux driver nightmare

Linux Hater is right in many of his claims, especially when talking about (non-existing) ABI or even API compatibility of the Linux kernel across versions. Everything is fine as long as your hardware is working out-of-the-box, but as soon as something is not supported out-of-the-box, you're up for a major nightmare.

The past few days, I've been trying to migrate one of our systems from Windows XP to Linux. That box has a few pieces of non-standard hardware installed, mostly sensor systems. Many of those drivers have not found their way into the kernel yet. So let's see..

  • Installed Xubuntu 8.04 LTS
  • Install kernel headers, build system, etc.
  • Contact vendor of USB Relais and ask for Linux kernel module
  • Surprisingly, got a module that (after minor modifications) compiles and even works!
  • Test USB camera. No luck with the Orange iBOT2. Apart from the iBOT2, our framework also supports UVC cameras. Bought a Logitech UVC camera (look out for the "Vista-ready" sticker), which works out of the box in Ubuntu 8.04! Yay!
  • Get and compile CAN driver. Seems to work nicely.
  • Contact measurement camera vendor, and ask for Linux drivers. Got drivers for a 2.4 kernel. After some investigation, also got experimental drivers for a 2.6 kernel that's been developed on 2.6.13 (and is GPL'ed OSS, btw).
  • Got the camera driver to compile and load on Hardy's kernel with major modifications. Getting camera info (like chip temperature) works fine, but grabbing images results in kernel panic. Unfortunately, grabbing pictures from the camera is a rather important feature...
  • Heard rumours that the camera driver works at least up to kernel version 2.6.17
  • Try to get kernel packages for something around 2.6.17. No luck on Hardy.
  • Clone vanilla kernel git repository, compile kernel 2.6.17. After several attempts, the self-compiled kernel even boots up!
  • Compile camera driver again. Grab a first picture! Yay!
  • Unfortunately, now the whole rest of the system is pretty broken. Hardy doesn't seem to like a manual kernel-downgrade.
  • Got the idea that it might be easier to upgrade a kernel, than to downgrade it. Killed the whole system and installed Xubuntu Dapper 6.06 LTS, which comes with kernel version 2.6.15. Maybe that version will work too, and I won't even need to upgrade..
  • Compile all external drivers again
  • Test if the UVC camera still works. Of course -- it doesn't.
  • Download UVC kernel module from svn (there are no snapshots available). Try to compile it -- no luck. Try to find the latest svn revision number that actually compiles with Dapper's kernel by bisection. Compiled and loaded that kernel module.
  • Now, let's test with our framework
  • Oh no -- our framework depends on newer versions of installed libraries (Boost, Qt, etc. pp.) than what is available for Dapper. Grab Boost, Qt, and all other libs from upstream, and compile them.
  • Oh no, the cmake build system backported to Dapper doesn't contain all necessary modules either (FindPkgConfig.cmake, others). Get those modules as well. No need to say that the backported cmake build system behaves slightly different to what is installed on Hardy as well.
  • Compile and start the program. Oh no, crash deep inside Qt. Right -- no OpenGL support without proprietary graphics drivers. Install those as well.
  • Test UVC camera. It works!
Being a supporter and developer of OSS software myself, I can understand the reasons of the kernel developers for not maintaining a stable ABI (or even API) for kernel modules. But for the user, this is just a major pain, that ultimately renders Linux unusable on many environments.

Sunday, May 18, 2008

Reactions to the Debian - OpenSSL - disaster

I really wanted to abstain from commenting the Debian OpenSSL disaster. I have however read far to many false claims and bloodcurtling comments to leave them uncommented.

Clearly, the Debian's OpenSSL maintainer has messed up seriously. Very seriously. He is the one to blame for thousands of machines being easily attackable during a time period of about 2 years.

It's not as if the OpenSSL team was unblamable of this misery though.

  • The original query of the Debian Developer resulted in an unfortunate answer of an OpenSSL team member, and other than that ignorance. Another mail about a year later clearly says that a patch commenting out those lines made it into Debian, again with no feedback, so even the "If OpenSSL had known that this should go into Debian..." argument is invalid. I wonder why, since an OpenSSL guy claims that this mistake is so obvious and that upon seeing the patch, "we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was."

    I am not going to comment on the the claim that openssl-dev was the wrong mailing list, as Branden's blog post leaves nothing to add on that topic.

  • The claim that making OpenSSL Valgrind-clean is just a minor, unimportant cosmetic fix is wrong. The OpenSSL library is typically used by programs with network access. The developers of these programs often use Valgrind to catch memory access failures, which could easily compromise the security of the machine if not detected. Being able to Valgrind your code without drowning in OpenSSL warnings and errors is an important thing.

    Using very questionable (see point below) constructs in the code without even a source code comment is not something to be proud of either.
  • The claim that the original OpenSSL code is not buggy is wrong. The claim that the "harmless" part of the disastrous patch is just harmless is wrong. It fixes a serious bug in OpenSSL. Using uninitialised objects with allocated or automatic storage results in undefined behavior in C.

    It may add Entropy to the pool. It may crash. It may send out a tarball of your .ssh and .gnupg directories to ronald@mcdonald.com without letting you know.

    All three options (and any other option) is completely valid at program run time, or even at compile time.

    For example, this is a program that I use to predict the lottery numbers of the next five years:

    #include <stdio.h>

    int main()

    {

    int a;

    a++;

    printf("%d\n",a);

    return 0;

    }


    What? This doesn't work for you? Welcome to the wonderful world of undefined behavior.

    In the light of this, above linked comments sound almost ironic.

I feel Debian has learnt a lesson out of this. Can the OpenSSL team say the same?

Disclaimer: These are solely my oppinions. I speak for no project or company or whatever. I am in no way affiliated to either OpenSSL or Debian. Both are outstanding, impressive free software projects.

Tuesday, March 4, 2008

Claws Mail goes OpenSync - progress report

It's been a while since my initial announcement of the Claws Mail - OpenSync connection. Addressbook and calendar synchronisation are a pretty important topic for me. I hate trying to keep all those addressbooks or calendar events on PDAs or cell phones in sync manually. It is a lot of hassle - and ultimately just doesn't work.

The OpenSync guys came up with a pretty well thought-out synchronisation framework that sounded interesting enough to invest some rainy Saturday afternoons and hook up Claws Mail with it.

Now that contact synchronisation is going better and better, I decided to make my hands dirty on calendar events as well. Colin, being the author of Claws Mail's vCalendar plugin, helped me out and implemented part of my calendar interface wishlist in the vCalendar plugin. As a result, one-way syncs of calendar events from Claws Mail to OpenSync counterparts are possible.

As a proof of concept, let's use a Claws Mail / EDS sync group to show upcomming calendar events in the GNOME clock:


It's far from being complete (and even farther from being usable), but it's an encouraging progress.

Hosting moved to github. There's one repository for the OpenSync plugin for Claws Mail, and another repository for the Claws Mail plugin for OpenSync. You'll need both if you want to try this out. Also, the plugin for OpenSync requires a pretty recent (probably svn) version of OpenSync up and running.

Tuesday, February 12, 2008

Licence fun

If a piece of software wants to link against GPL'd code, it has to be GPL-compatible. To be more accurate, it has to be compatible with that specific GPL version. So far so good.

Now, GPLv2 and GPLv3 are incompatible. As a consequence, code under GPLv2 and GPLv3 cannot be combined. This has nasty consequences.

This time it's not Claws Mail that bites, but it got bitten back by ClamAV. Claws Mail is licenced under GPLv3 or later. It has an optional plugin for email antivirus-scanning that uses libclamav, which is licenced under GPLv2 (only). Do you see it comming? That plugin, even if itself licenced under GPLv2 or later and thus in theory compatible with both sides that it is supposed to connect, is itself illegal.

In fact, you can take the FSF GPL FAQ, section "Combining work with code released under the GNU licenses", read "non-free" or "proprietary" as a synonym for "licenced under GPLv2", and the statements remain valid.

Isn't that ironic, at best?

Now, what is the way out? Colin asked the FSF about the problem, and the options are basically to

  • convince ClamAV to put their library under a licence compatible to GPLv3
  • have libclamav grant Claws Mail specific permission to link libclamav
  • change Claws Mail's licence to GPLv2 or later
It is also possible to
  • roll out ClamAV's functionality into separate processes (fork(), exec() is legal)
  • just drop the ClamAV plugin
Fun, isn't it?

Wednesday, January 23, 2008

Hello World! test post

This is the mandatory test post. I got this blog a long, long time ago, but never used it. Future will show whether or not I will have some random thoughts to share.