In a recent lkml thread the concept of dumping an image of the kernel's memory to swap when the kernel hits a bug was discussed. Linus Torvalds pointed out that such a feature wasn't useful to an operating system like Linux that can ran on such a diverse assortment of computers, "yes, in a controlled environment, dumping the whole memory image to disk may be the right thing to do. BUT: in a controlled environment, you'll never get the kind of usage that Linux gets. Why do you think Linux (and Windows, for that matter) took away a lot of the market from traditional UNIX?" He went on to explain that there are systems where swap is not larger than the size of the core so collecting a crash dump would not be possible, that Linux instead tries to acknowledge bugs without crashing, and quite often the bug is actually in the drivers, "writing to disk when the biggest problem is a driver to begin with is INSANE." Comparing Linux to Solaris he added, "so the fact is, Solaris is crap, and to a large degree Solaris is crap exactly _because_ it assumes that it runs in a 'controlled environment'."

Alan Cox went on to point out that there are also privacy issues, "there is an additional factor - dumps contain data which variously is - copyright third parties, protected by privacy laws, just personally private, security sensitive (eg browser history) and so on. The only reasons you can get dumps back in the hands of vendors is because there are strong formal agreements controlling where they go and what is done with them." He went on to note that dump utilities are also not user friendly, "diskdump (and even more so netdump) are useful in the hands of a developer crashing their own box just like kgdb, but not in the the normal and rational end user response of 'its broken, hit reset'". Linus heartily agread, and suggested that anyone willing to use kernel dumps would be better off debugging through a firewire connection, " if you've ever picked through a kernel dump after-the-fact, I just bet you could have done equally well with firewire, and it would have had _zero_ impact on your kernel image. Now, contrast that with kdump, and ask yourself: which one do you think is worth concentrating effort on?"

A recent discussion on the lkml examined the possibility of a Linux implementation of Sun's ZFS. It was pointed out that the file system is released under the GPL-incompatible CDDL, and that Sun has filed numerous patents to prevent ZFS from being reverse engineered. Max Yudin pointed out, "according to Jeff Bonwick's blog Sun issued 56 patents on ZFS, but I have no idea what they patented. Sorry, binary compatible ZFS reimplementation with GPL license might not be legal." David Litwin noted that he had been told by a ZFS developer to talk to Linux developers to see about getting non-GPL'd code included with the kernel. Theodore T'so replied, "that was totally useless answer from the ZFS developers. What he should have told you is to contact Sun management, since they are the only ones who can decide whether or not to release ZFS under a GPL license, and more importantly, to give a patent license for any patents they may have filed in the course of developing ZFS."

Alan Cox [interview] suggested, "the real test of whether Sun were serious about ZFS being anywhere but Solaris is what they do to license it - they've patented everything they can, and made the code available only under licenses incompatible with other OS products. Their intent is quite clear, and quite sad. Compare it to what the old Sun company did with NFS, which is now a standard used everywhere." Theodore T'so added, "given that Sun has reportedly filed a huge number of patents covering ZFS and has refused to make them available for anything other than Solaris --- and there are senior Sun programmers who have on record stated that one of the reasons why Sun picked the CDDL was precisely because it was incompatible with GPL and Sun fears Linux ---- I wouldn't bet on Sun being willing to making a patent license available to a hypothetical alternate implementation of the ZFS format for Linux." He went on to note, "of course, this is all open source. If someone wants to work on reimplementing ZFS from scratch, either in userspace or in the kernel, certainly the Linux community won't stop them. Given the patent issues Linus might not feel comfortable including it in the mainline sources without a promise from Sun that they won't sue the pants off of him and The Linux Foundation, but again, that's Sun's decision, and no one else can help you there."

A recent security advisory announced today by Rapid7 explains, "the NVIDIA Binary Graphics Driver for Linux is vulnerable to a buffer overflow that allows an attacker to run arbitrary code as root. This bug can be exploited both locally or remotely (via a remote X client or an X client which visits a malicious web page). A working proof-of-concept root exploit is attached to this advisory." The advisory goes on to note that the FreeBSD and Solaris binary drivers are also likely vulnerable to the same flaw and cautions, "it is our opinion that NVIDIA's binary driver remains an unacceptable security risk based on the large numbers of reproducible, unfixed crashes that have been reported in public forums and bug databases."

Chad Loder [bio], Rapid7's Manager of Engineering, explained that NVIDIA has known about this bug in their binary driver for some time, "the link in the advisory is the earliest thread in which we could find an NVIDIA employee publicly acknowledging the bug, although it was reported back in 2004 and has probably existed even longer." Regarding the decision to announce the exploit to the public Chad explained, "I expect (or hope) that NVIDIA will fix the defect in their binary drivers quickly. I don't know anything about their development process or where their Linux drivers fit into their priority list. It seems that the majority of Linux users are perfectly willing to accept bugs in binary blob drivers from hardware vendors, so there is little incentive for NVIDIA to change their process."