The grumpy editor answers a call from CyanogenMod 7

The Android 2.3 "Gingerbread" release happened in late 2010, but that version of the operating system was initially only available to those who obtained a Nexus S handset. Your editor, not being one of those people, has had to wait a little longer. Nexus One owners running stock firmware have been receiving updates for a few weeks as of this writing. Those running CyanogenMod have yet to see a stable Gingerbread-based distribution, but their wait, too, is coming to an end; CyanogenMod 7.0.0-rc2 was announced on March 8. Your editor, never afraid to brick an expensive handset, decided to give this release candidate a try. Talking on the phone is overrated anyway.

The initial experience says that there is little need to worry; this release candidate seems to be stable indeed on the Nexus One. Your editor's careful Nandroid backup, it seems, will not be needed; there is no evident reason to go back to the older code. That said, there are reports of a "wonkiness issue" which affects phone calls in rc2; your editor has not yet seen this behavior but others certainly have. Smarter CyanogenMod users may want to wait for the official 7.0 release before updating.

Naturally, CyanogenMod 7 brings all of the enhancements that Google put into the Gingerbread release. The new color scheme is nice - though some applications (WeatherBug, for example) have not yet caught up to a world where writing black text into the (now black) notification bar fails to yield the desired results. The improved on-screen keyboard is most welcome; it seems easier to avoid typing mistakes and the number of needed mode-shifts is reduced. Most welcome are the ability to apply the spelling corrector anywhere in a message and a comma key which does not require a mode shift to reach.

Some other 2.3 features look nice, but your editor has not, yet, had the ability to try them out. Near-field communications are not supported by the Nexus One, and there is no nearby place to use that capability yet in any case. For the time being, perhaps, being unable to spend money directly with the handset is not an entirely bad thing. This release also supports Internet telephony via an outside SIP provider, a feature which certainly merits exploration at some point.

Nexus One users wanting the features found in the 2.3 release can, of course, just use the stock firmware which is nicely delivered via an over-the-air update. Owners of other handsets may not get any such service. One of the most valuable features of CyanogenMod is the large number of handsets supported; for many, it may be about the only way to get a current Android distribution on their phones.

But, naturally, there is more to CyanogenMod than ports; it also brings a number of features of its own. At the top of the list must be simple configurability. There is (once again) an apparent trend in parts of the free software community to remove configurability from systems in the name of "user friendliness"; sometimes distributions like Android are held out as examples of successful application of this approach. The CyanogenMod developers have not bought into that idea.

With CyanogenMod, one can set the color of the notification LED based on which application is trying to communicate something - email updates can be pink, missed calls yellow, and text messages a deep blue. There are three variants on the basic lock screen, with options for music player controls and access to a user-chosen application without unlocking the screen. The home screen/application launcher application has options controlling screen layout, whether the wallpaper scrolls, various gesture actions, where the trash can sits, and a vast number of other things. There is also a theme mechanism and, happily, a means to back up and restore all those settings. Other options control what happens when the search button is pressed, how hard the phone vibrates in response to various types of key events, which hours of the day the phone should be silent, and more. If you truly want to change which CPU frequency governor is used, or if you want to render the home screen in green only, CyanogenMod makes it possible.

The "power control" widget follows the same theme. The contents of this widget are under user control, with far more options (WiFi hotspot, mobile data, 2G/3G, etc.) than stock Android provides. One can even control the all-important flashlight capability through the power widget. An especially nice feature is the ability to make connections between some of the settings; for example, application synchronization can be enabled only when WiFi is enabled. That allows the cautious use of data in international-roaming environments without the danger of being bankrupted by a surprise application update.

All told, CyanogenMod's configuration options can seem a bit overwhelming, especially since their effect is not always obvious. But for somebody who makes a lot of use of their handset, a half-hour or so spent doing a depth-first traversal of the settings menus can go a long way toward optimizing the device's behavior.

Other CyanogenMod features include an "incognito" mode for the web browser, support for FLAC files in the music player (which has been "restyled" in a number of ways), SMS templates available via gestures, "phone goggles" (an outgoing call blocking mechanism), openVPN support, a dynamic equalizer for audio output, various hardware enablement and performance improvements, and much more.

Perhaps the real value of CyanogenMod, though, is that it turns Android into something resembling a real open source project. They take Google's code dumps and turn them into a working system which can be built and enhanced by anybody. The community around the distribution appears to be growing, and it is slowly developing the sort of infrastructure that a community-oriented project should have (even if they still insist on using obnoxious forums for their communications). Many people repackage Android binaries; CyanogenMod seems nearly alone in working at the source level. The result is a phone which works better for its users and which improves over time. It's hard to be grumpy about that.

Comments (19 posted)

Enterprise distributions and free software

The "enterprise distribution" business is a bit of a funny one; it often seems like an attempt - by vendors and customers both - to fit free software back into the business model long used by proprietary operating systems vendors. It will necessarily create some tensions between the values of the free software community (including free access, rapid development, and collaboration) and those of the business, which include rigid stability and the preservation of competitive advantage. Recent changes made by Red Hat show the effects that this tension can cause, especially when combined with strong, arguably unfair, competition.

The core Red Hat Enterprise Linux (RHEL) distribution is built entirely on free software (the supplementary repository includes a few third-party proprietary bits like Flash). The source for the distribution is freely available and freely distributable by any other party as long as trademark-relevant bits are stripped out. This freedom is exploited by free distributions like CentOS and Scientific Linux; it is also exploited by commercial competitors who are happy to charge money to support the distribution that Red Hat has made.

Naturally, it is the commercial competitors that are creating the most trouble for Red Hat, which invests a considerable amount of money into the development of both the software on which RHEL is based and the creation of RHEL itself. Companies like Oracle also contribute to upstream projects, but on a rather smaller scale, and they contribute little indeed to the development and maintenance of the RHEL distribution. Freed of that expense, these companies are able to offer support for Red Hat's distribution (or derivatives thereof) while charging much less. They are said to be actively courting Red Hat's existing customers, with a certain amount of success. It seems like a clear path to a successful business, even without the darker allusions, heard occasionally, that the real intent is simply to drive Red Hat out of business.

Given this situation, it is not entirely surprising that Red Hat has decided that it needs to respond; a company which makes life too easy for its competitors tends not to stay around for long. The company could try to make its distribution more proprietary to keep others from redistributing it. The use of proprietary kernel modules to this end is not unheard of, but it would be surprising indeed to see Red Hat take that approach. Proprietary user space components, like those used by Google to keep some control over Android, would have fewer licensing difficulties, but it still would be a major change for a (previously) free distribution. The good news is that Red Hat has resisted any such pressures - so far.

What Red Hat is doing is still seen by many as being something other than good news, though. Essentially, Red Hat is asserting stronger proprietary control over the metadata it possesses about the RHEL distribution. That metadata includes its "knowledge base" of problems and solutions, bugs and fixes, etc. What Red Hat wants to do is to exploit the advantage gained from having built and supported RHEL over all these years, and to make it harder for others to exploit that knowledge. The company is trying to compete by providing better support, and one way to have better support is to keep your competitors from making their own support offerings better through the use of your own information and experience.

Kernel source packaging

The move that brought all this to the community's attention was a change in the way that the source RPM file for the RHEL 6 kernel is packaged. Traditional source-packaging practice is to combine an unmodified upstream tarball, a set of distributor patches, and a script (the "spec file") which applies the patches and builds the software. The RHEL kernel package, instead, consists of a single tarball reflecting the kernel in its fully-patched form. There is a long list of patch titles in the spec file, but there is no other information which can be used to recover the specific patches which have been applied to the kernel.

The purpose of this change, evidently, is to make it harder for competitors to figure out why specific patches were made. Many changes applied to the RHEL kernel will have been done in response to specific customer problems; the understanding of those problems and how they were fixed will, at times, be useful in future support situations. By mixing all of its patches into a single, lossy tarball with no changelogs, Red Hat hopes to deprive others of this useful support information.

Will it work? The restriction of information in general should certainly deprive competitors of a useful resource, though the cynical might note that access to that information could be restored via an inexpensive low-end RHEL subscription. Whether broken-out patches for the kernel, in particular, are useful to competitors is not entirely clear. It may well be that Red Hat has irritated - and possibly made life harder for - the development community without bothering anybody else in any appreciable way.

Red Hat claims that the packaging change should not bother the development community at all, noting that the change had been in effect for four months before complaints were heard. One of the foundations of this claim is the fact that the RHEL "2.6.32" is far removed from anything called "2.6.32" anywhere else; the company once described it this way:

This kernel is a sort of Frankenstein's monster of fixes and backports; it is a distant relation to any sort of upstream kernel. Given that, Red Hat has said, most patches to this kernel do not apply in any useful way to the kernels the rest of us are working with. In other words, they claim, there is no value to the community in most of the RHEL kernel patches.

More importantly, though, Red Hat insists that it is a strong believer in working upstream. Any patches developed by Red Hat which have any relevance to upstream kernels are promptly sent upstream for merging. This line of reasoning suggests that there will not be anything of interest to the community in RHEL kernels; everything of value will have already been submitted for merging. The company's history backs up this claim; its history of contributions is matched by few others, and, by all accounts, the practice of contributing upstream is wired deeply into the company's culture.

That said, maintainers of the community stable kernels (and some other developers as well) have been heard to complain that Red Hat's practice is making work harder for them. Beyond that, though, this practice leaves the community with a bit of a bad taste in its mouth. The development of a significant fork of the Linux kernel has become more closed in a possibly ineffective attempt to support corporate interests. The fact that those corporate interests are in the personal interests of everybody whose salary is paid by that company and by everybody who benefits from that company's contributions perhaps softens the blow, but it does not make everything better. Many people are left wondering what the next step will be.

The enterprise distribution business

They may be right to wonder. The "enterprise distribution" business model, as it is currently implemented, is a strange distortion of the development community that supports it. It is said by some to violate the GPL, or, at least, to stretch its spirit to the breaking point; that is a subject which will be examined in another article. Of interest here is the fact that this model also led to the creation of kernels so divergent that its simple fixes no longer apply to the mainline. Your editor can't help thinking of Andrew Morton's classic keynote at the 2004 Ottawa Linux Symposium:

The RHEL kernel, which is certainly differentiated from any other kernel out there, would seem to be well described by Andrew's words. Red Hat's move to lock down information about this kernel is an admitted attempt to increase customer lock-in; they are trying to make it harder to move to another provider of support. Is this good for Linux?

Corporate moves do not happen in a vacuum; Red Hat's competitors will likely come up with responses of their own. Perhaps they will just develop other sources for the information they need. If, instead, they adopt a strategy like Red Hat's, we could end up with a fragmented range of incompatible Linux distributions, each of which tries to lock in customers with its own combination of unique features and proprietary information. Veterans of the Unix wars can be forgiven for shuddering a bit at that thought.

An alternative might be to move away from the idea of "frozen" kernels in enterprise distributions. The truth of the matter is that these kernels are far from frozen; RHEL's "2.6.32" kernel has features from 2.6.38 - and probably beyond. Nobody wants a kernel which was set in stone years before, so these "stable" kernels get no end of features backported into them. The result is a combination which has never been seen before in nature and which may have stability problems of its own. It is also expensive to create and expensive to maintain.

Perhaps enterprise distributions should stick closer to mainline kernels and even move to new releases occasionally? Oracle's "Unbreakable Enterprise Kernel" looks like a move in that direction. Novell did something similar with its SP1 update to SUSE Linux Enterprise 11. This approach would seem to offer some real advantages: users would get new features and fixes from upstream, and distributors would not have to pay the cost of creating and maintaining a highly divergent kernel. There would also be less need to treat related information as proprietary; companies would compete on their ability to support current mainline software, rather than a vendor-specific kernel. That seems like an environment in which Red Hat, which does so much to create mainline kernels, could compete most effectively.

Of course, anybody who listens to business advice from your editor has a strong chance of learning all about the bankruptcy process in short order. Beyond that, this is not a new idea; it was discussed here in 2007. The ultra-stable enterprise distribution model seems to be in no danger of going away, in any case, even though some vendors seem to be experimenting with some changes. There are customers, it seems, so there will be vendors.

In the end, companies need to make money or they disappear. Red Hat has, so far, found ways to keep its stockholders happy while supporting the development community which makes it all possible. One can only hope that, as this market becomes more competitive, the companies involved will continue to find a way to balance those important interests; the alternative, certainly, will be destructive to both.

Comments (77 posted)

Red Hat and the GPL

The changes that Red Hat has made in the way it releases kernel source for RHEL 6 have stirred up some controversy. There is a certain tension between the needs of an enterprise distribution and the interests of the free software projects on which it is based. While the changes that Red Hat has made do not seem very popular, there has also been a fair amount of speculation that the move somehow violates the GPL, which is a rather serious charge. But there is good reason to believe that Red Hat is not crossing into GPL-violation territory, though it may well be sitting close to that line.

First, the obvious: Red Hat has a top-notch legal team, with a lot of GPL experience, so it's a little hard to believe that those lawyers, at least, haven't examined Red Hat's position and believe it is defensible in the unlikely event of a lawsuit. While Red Hat has a legal team, LWN seems to be lacking in the legal budget department, so nothing in this article should be considered legal advice of any sort (I am not a lawyer, nor do I play one anywhere).

The arguments being made about GPL compliance seem to fall into two categories. The first is that distributing what is effectively a tarball of the kernel source does not qualify as the "preferred form of the work for making modifications to it" (as is specified in the GPL). While the second is that making the individual patches to the kernel source available to customers, but not allowing those customers to redistribute the patches to others, puts a "further restriction" on GPL-covered code (which the patches clearly are). While neither complaint is completely without merit, both would seem to fall short of GPL violations.

Preferred form

While there can certainly be arguments about what "preferred form" means for source code distributions, Red Hat's actions here don't seem very close to the line. The basic idea is that the code be released in digital form, along with any build scripts, so that downstream developers can reproduce the GPL-covered binary that is being shipped. It is partly meant to prevent recalcitrant vendors from releasing the source on paper—or stamped into clay tablets in cuneiform. One could argue that those methods do provide the source code, but it certainly isn't in a form preferred by anyone—nor does it adhere to the "medium customarily used for software interchange" requirement.

Obfuscated source code, where all the variables and function names get turned into unintelligible gibberish, or the source is deliberately split up in ways that are harder to work with, are a bit more of a gray area—but not much. Those kinds of actions should be seen as clear attempts to circumvent the GPL requirements. But that's not at all what Red Hat is doing.

The tarball that Red Hat is releasing may not be the preferred form for the Red Hat kernel developers to use, but that is not part of the requirement. Tarball releases of GPL code are a longstanding tradition in the free software world. Many projects still do it that way and the FSF itself has made releases that way in the past. While it is nice to get some visibility into the version control system of a project, it certainly isn't required for GPL compliance. No one complained that Red Hat didn't provide access to its Git repositories back when it was still providing the broken-out patches, for example. A Git repository is definitely the preferred form for Red Hat developers to use, but there are lots of reasons that the company might want to keep its repositories to itself—something that is obviously within its rights.

There is an oft-ignored GPL clause about modifications to consider here as well: "You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change." Red Hat may well be technically violating that clause, but it is hardly alone in that as it is pretty much completely ignored by everyone, without any real consequences. But this GPL requirement is of little interest to most. What everyone really wants is the reason that the change was made (along with which changes to other files go along with it), and the GPL is silent on any requirement to provide that level of detail.

For the RHEL kernel source, what Red Hat is providing is well within the GPL boundaries. It is also well within community norms. The community gets kernel tarballs from lots of companies (often those in the embedded Linux world), sometimes after a bit of a struggle, and is happy to get them. Red Hat shouldn't be treated any differently than those companies are with respect to the distribution of source code. Tarballs may be something of a barrier to easier collaboration, debugging, and so on, but distributing them doesn't rise to anything near a GPL violation. The other major complaint, on the other hand, is a bit less clear cut.

Trading GPL rights for support

While it isn't anything particularly new, some aspects of the RHEL support model are raising eyebrows in light of the changes to the kernel source distribution. In particular, the broken-out patches that used to come with the kernel source RPMs are evidently being made available to Red Hat customers, but only if they don't distribute them further on pain of losing support going forward. This sounds like a restriction on the GPL rights of the recipients of the patches—and it is—but that restriction is enforced via an agreement between Red Hat and its customers.

This is part of Red Hat's business model that Bradley Kuhn calls the "'if you like copyleft, your money is no good here' business model" (scroll down a ways to get to that part of his post). It is, he says, GPL-compliant "merely because the GPL is silent on whether or not you must keep someone as your customer". He also says that Red Hat was the first to make use of that particular business model, but he may be forgetting about Sveasoft.

The history is fading into link rot a bit at this point, so it is possible that Red Hat was the first to get there. But Sveasoft's subscription model, which essentially required subscribers to give up their distribution right on GPL-covered code provided by Sveasoft, was roundly criticized in the early 2000s. In 2004, though, Sveasoft announced that the FSF had reviewed and, somewhat surprisingly, at least at the time, approved that arrangement. Essentially, the support (or subscription) agreement is a contract between two entities and those parties can agree to pretty much anything they want. The GPL cannot protect one from agreeing to refrain from certain behavior.

In the distant past, there were also complaints that Red Hat will terminate its support contract for users that run their own kernel, rather than what is supplied with RHEL. While that is another restriction on exercising GPL rights, it is one that is rather easier to understand. Trying to support any random kernel that a customer wants to run is likely to be a quick way to drive Red Hat's kernel engineers mad. Complete termination of support may be an excessive reaction—and is probably rarely if ever used—but certainly not supporting those systems running other kernels is not an unreasonable position.

The inability to redistribute the kernel patches is clearly seen by some as the most egregious "violation" of the GPL rights of its customers. In some, possibly many, cases those patches are not even owned by Red Hat, but were instead submitted by others to the upstream kernel and then integrated or backported into the RHEL 6 kernel. But the results of that effort are being distributed in source form. If Red Hat's customers are willing to trade their GPL rights for support, there is little anyone else can do but complain.

On the other hand, a sufficiently motivated group could probably reverse-engineer the patches from the RHEL 6 kernel source. It would be a tedious and error-prone process, but Red Hat has said that all of the RHEL 6 features have been submitted upstream, so it should be doable. Anyone with a RHEL support contract would want to think long and hard before participating in such a project, however. Whether there is sufficient value in doing so remains to be seen.

Comments (164 posted)

The future of vendor-sec

There is a certain amount of irony in the news that the vendor-sec mailing list—along with the server that distributes it—was compromised. Vendor-sec is the closed mailing list that is used by developers of Linux distributions along with members of the BSD development community ("vendors" by some definition) to discuss security problems before they are made public. So a compromise of the mailing list could easily lead to security issues made "public" well before fixes were available—an attacker's dream scenario.

How exactly the server was compromised is not clear, but a short time after the announcement of the server compromise and closing the backdoor that was being used, the attacker returned. Vendor-sec moderator Marcus Meissner reported some five hours later that "the attacker read this [the announcement] and reentered the lst.de machine, went amok and destroyed the machine's installation. The machine has now been shutdown.". The break-in was noticed a week or so before the announcement, which seems like somewhat tardy notice to those who might be posting to vendor-sec, but, worse yet, the best guess for when the original break-in occurred is January 20—more than a month earlier.

During that time—possibly longer—the attacker could have been reading the "secret" traffic on the list. Vendor-sec is nominally used to coordinate response between the participants, and to embargo information about the vulnerabilities until all are ready with a fix. Obviously, an embargo is not likely to be observed by an attacker. But it's certainly not at all clear that vendor-sec was leakproof prior to the break-in.

According to Meissner's announcement, there are 80-100 people signed up for vendor-sec, so expecting that there are no leaks may be overly optimistic. Even if all of the participants maintain the secrecy, though, the messages were sent in the clear so they could be intercepted along the way, dug out of inboxes by system administrators, or snagged from unattended mail clients. Since at least January 20, of course, someone didn't even need to do any of those, which started Meissner thinking about whether a closed list like vendor-sec is even really needed any more, and if it is, what changes might need to be made. So he threw that out for discussion.

The consensus seems to be that there is value in the closed list, but that leaks should probably be expected—hopefully not from attackers, but via list members by mistake, inattention, or, possibly, malfeasance. Meissner has asked Alexander Peslyak (aka Solar Designer), who runs the oss-security list and is the leader of the Openwall Linux distribution, to take over vendor-sec, and part of that might mean that the messages start being encrypted with GPG. That would stop some of the potential leak sources, but obviously not all. But there were also questions about whether the list should be split up and, if so, how.

Solar Designer suggested splitting the list up into three different lists, one each for Linux, BSD, and security researchers. The idea would be that subscribers would get less mail that isn't relevant to their interest area, but others thought that was unnecessarily complicating things. As Eugene Teo put it: "I think it is more effective to have just one mailing list like before that everyone can remember."

There is discussion of having oCERT (Open Source Computer Emergency Response Team) host a vendor-sec-style mailing list. oCERT already has verified contacts that could be used to disseminate non-public security information to various projects as needed. Andrea Barisani, oCERT project coordinator is open to such an arrangement, though it would likely require more team members to handle the workload. It could turn into a lot of additional work as Barisani describes:

So far, no real decisions have been made. Some kind of vendor-sec list seems to be useful, but whether it stays a single list, and where and how it will be hosted are up in the air. Even though few are arguing that vendor-sec should go away, there was some interesting data from Mark J. Cox about the trends of reports to vendor-sec. Over time, it would seem that the number of issues being reported first to vendor-sec have dropped significantly.

Cox keeps track of how the Red Hat security team first finds out about vulnerabilities, and the data suggests that the importance of vendor-sec for that purpose is diminishing. In 2008, 69 issues were found first on vendor-sec, but by 2010 that had dropped to 29. According to Cox, 29 represents just 4% of the total number of vulnerabilities fixed. In addition, the severity level of those problems first reported to vendor-sec were not as high as some expected: "Of the flaws we rated impact critical or with a CVSS [Common Vulnerability Scoring System] of 'high', only 4 were from that 29 from vendor-sec."

There may come a time when vendor-sec (or whatever it becomes) is no longer needed, but we seemingly haven't reached that point yet. There are times when coordinating a fix (and establishing a CRD, coordinated release date) is important to protect end-users from severe, non-public vulnerabilities. While "full disclosure" is preferred by some, others are sold on "responsible disclosure"; as long as that's the case, lists like vendor-sec will need to be available to help orchestrate those releases.

Comments (4 posted)

Security quotes of the week

-- Dave Aitel (Thanks to Buck Huppmann.)

-- Frédéric Buclin

-- John Gilmore

Comments (7 posted)

An Android security update from Google

Google has posted an advisory on the recent malware distributed through the Android market and how the company is responding. "We are pushing an Android Market security update to all affected devices that undoes the exploits to prevent the attacker(s) from accessing any more information from affected devices." It's worth noting that the exploit used known vulnerabilities in older versions of Android; there is little in the advisory about closing those holes before they are exploited.

Comments (15 posted)

Vendor-sec host compromised, shut down

The vendor-sec list is where distributors discuss security problems which have not yet been disclosed to the public. It turns out that the machine which hosts this list was compromised, probably in January, and any subsequent traffic was not as secret as participants may have hoped. Since the announcement, the machine has been totally vandalized by the attacker, and vendor-sec is down. The thread is interesting to read; much of it concerns whether the community still needs a closed list like vendor-sec or not.

Full Story (comments: 4)

dtc: multiple vulnerabilities

Package(s):	dtc	CVE #(s):	CVE-2011-0434 CVE-2011-0435 CVE-2011-0436 CVE-2011-0437
Created:	March 3, 2011	Updated:	March 9, 2011
Description:	From the Debian advisory: CVE-2011-0434: The bw_per_moth.php graph contains an SQL injection vulnerability. CVE-2011-0435: Insufficient checks in bw_per_month.php can lead to bandwidth usage information disclosure. CVE-2011-0436: After a registration, passwords are sent in cleartext email messages. CVE-2011-0437: Authenticated users could delete accounts using an obsolete interface which was incorrectly included in the package.
Alerts:	Debian DSA-2179-1 dtc 2011-03-02

Comments (none posted)

kernel: privilege escalation

Package(s):	linux-ec2	CVE #(s):	CVE-2011-1044
Created:	March 3, 2011	Updated:	August 9, 2011
Description:	From the Ubuntu advisory: Dan Carpenter discovered that the Infiniband driver did not correctly handle certain requests. A local user could exploit this to crash the system or potentially gain root privileges. (CVE-2011-1044)
Alerts:	SUSE SUSE-SU-2012:1391-1 Linux kernel 2012-10-24 Ubuntu USN-1204-1 linux-fsl-imx51 2011-09-13 Ubuntu USN-1202-1 linux-ti-omap4 2011-09-13 Ubuntu USN-1187-1 kernel 2011-08-09 Ubuntu USN-1186-1 kernel 2011-08-09 Scientific Linux SL-kern-20110715 kernel 2011-07-15 CentOS CESA-2011:0927 kernel 2011-07-18 Red Hat RHSA-2011:0927-01 kernel 2011-07-15 Ubuntu USN-1167-1 linux 2011-07-13 Ubuntu USN-1093-1 linux-mvl-dove 2011-03-25 Red Hat RHSA-2011:0330-01 kernel-rt 2011-03-10 Fedora FEDORA-2011-2134 kernel 2011-02-24 Ubuntu USN-1080-2 linux-ec2 2011-03-02 Red Hat RHSA-2011:0498-01 kernel 2011-05-10

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2010-4076 CVE-2010-4650 CVE-2011-0006 CVE-2011-0710 CVE-2011-0711 CVE-2011-0712
Created:	March 8, 2011	Updated:	August 9, 2011
Description:	From the SUSE advisory: CVE-2010-4076: The rs_ioctl function in drivers/char/amiserial.c in the Linux kernel did not properly initialize a certain structure member, which allowed local users to obtain potentially sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call. CVE-2010-4650: Fixed a verify_ioctl overflow in "cuse" in the fuse filesystem. The code should only be called by root users though. CVE-2011-0006: Fixed a LSM bug in IMA (Integrity Measuring Architecture). IMA is not enabled in SUSE kernels, so we were not affected. CVE-2011-0710: The task_show_regs function in arch/s390/kernel/traps.c in the Linux kernel on the s390 platform allowed local users to obtain the values of the registers of an arbitrary process by reading a status file under /proc/. CVE-2011-0711: A stack memory information leak in the xfs FSGEOMETRY_V1 ioctl was fixed. CVE-2011-0712: Multiple buffer overflows in the caiaq Native Instruments USB audio functionality in the Linux kernel might have allowed attackers to cause a denial of service or possibly have unspecified other impact via a long USB device name, related to (1) the snd_usb_caiaq_audio_init function in sound/usb/caiaq/audio.c and (2) the snd_usb_caiaq_midi_init function in sound/usb/caiaq/midi.c.
Alerts:	Oracle ELSA-2013-1645 kernel 2013-11-26 openSUSE openSUSE-SU-2013:0927-1 kernel 2013-06-10 Ubuntu USN-1394-1 Linux kernel (OMAP4) 2012-03-07 Ubuntu USN-1218-1 linux 2011-09-29 Ubuntu USN-1216-1 linux-ec2 2011-09-26 Debian DSA-2310-1 linux-2.6 2011-09-22 Ubuntu USN-1208-1 linux-mvl-dove 2011-09-14 Ubuntu USN-1204-1 linux-fsl-imx51 2011-09-13 Ubuntu USN-1203-1 linux-mvl-dove 2011-09-13 Ubuntu USN-1202-1 linux-ti-omap4 2011-09-13 Ubuntu USN-1187-1 kernel 2011-08-09 Ubuntu USN-1186-1 kernel 2011-08-09 Scientific Linux SL-kern-20110715 kernel 2011-07-15 CentOS CESA-2011:0927 kernel 2011-07-18 Ubuntu USN-1170-1 linux 2011-07-15 Red Hat RHSA-2011:0927-01 kernel 2011-07-15 Ubuntu USN-1167-1 linux 2011-07-13 Ubuntu USN-1159-1 linux-mvl-dove 2011-07-13 Ubuntu USN-1162-1 linux-mvl-dove 2011-06-29 Ubuntu USN-1164-1 linux-fsl-imx51 2011-07-06 Ubuntu USN-1183-1 kernel 2011-08-03 Ubuntu USN-1160-1 kernel 2011-06-28 Debian DSA-2264-1 linux-2.6 2011-06-18 Ubuntu USN-1146-1 kernel 2011-06-09 Ubuntu USN-1141-1 linux, linux-ec2 2011-05-31 Debian DSA-2240-1 linux-2.6 2011-05-24 Ubuntu USN-1133-1 linux 2011-05-24 SUSE SUSE-SA:2011:017 kernel 2011-04-18 openSUSE openSUSE-SU-2011:0346-1 kernel 2011-04-18 CentOS CESA-2011:0429 kernel 2011-04-14 Red Hat RHSA-2011:0429-01 kernel 2011-04-12 Red Hat RHSA-2011:0421-01 kernel 2011-04-07 Ubuntu USN-1105-1 linux 2011-04-05 SUSE SUSE-SA:2011:019 kernel 2011-04-28 Ubuntu USN-1093-1 linux-mvl-dove 2011-03-25 Ubuntu USN-1092-1 linux-source-2.6.15 2011-03-25 SUSE SUSE-SA:2011:015 kernel 2011-03-24 Ubuntu USN-1090-1 linux 2011-03-18 Ubuntu USN-1089-1 linux, linux-ec2 2011-03-18 Red Hat RHSA-2011:0500-01 kernel-rt 2011-05-10 openSUSE openSUSE-SU-2011:0416-1 kernel 2011-04-29 Ubuntu USN-1086-1 linux-ec2 2011-03-08 Fedora FEDORA-2011-2134 kernel 2011-02-24 SUSE SUSE-SA:2011:012 kernel 2011-03-08 Red Hat RHSA-2011:0498-01 kernel 2011-05-10 openSUSE openSUSE-SU-2011:0399-1 kernel 2011-04-28

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2011-0714
Created:	March 9, 2011	Updated:	March 9, 2011
Description:	The kernel's RPC server socket implementation contains a use-after-free flaw which can be exploited to cause a kernel oops.
Alerts:	Red Hat RHSA-2011:0329-01 kernel 2011-03-08

Comments (none posted)

libcgroup: multiple vulnerabilities

Package(s):	libcgroup	CVE #(s):	CVE-2011-1006 CVE-2011-1022
Created:	March 4, 2011	Updated:	May 27, 2011
Description:	From the Red Hat advisory: A heap-based buffer overflow flaw was found in the way libcgroup converted a list of user-provided controllers for a particular task into an array of strings. A local attacker could use this flaw to escalate their privileges via a specially-crafted list of controllers. (CVE-2011-1006) It was discovered that libcgroup did not properly check the origin of Netlink messages. A local attacker could use this flaw to send crafted Netlink messages to the cgrulesengd daemon, causing it to put processes into one or more existing control groups, based on the attacker's choosing, possibly allowing the particular tasks to run with more resources (memory, CPU, etc.) than originally intended. (CVE-2011-1022)
Alerts:	Fedora FEDORA-2011-2570 libcgroup 2011-03-04 SUSE SUSE-SR:2011:007 NetworkManager, OpenOffice_org, apache2-slms, dbus-1-glib, dhcp/dhcpcd/dhcp6, freetype2, kbd, krb5, libcgroup, libmodplug, libvirt, mailman, moonlight-plugin, nbd, openldap2, pure-ftpd, python-feedparser, rsyslog, telepathy-gabble, wireshark 2011-04-19 Pardus 2011-64 libcgroup pam_cgroups 2011-04-07 openSUSE openSUSE-SU-2011:0316-1 libcgroup1 2011-04-08 Fedora FEDORA-2011-2631 libcgroup 2011-03-04 Debian DSA-2193-1 libcgroup 2011-03-16 Red Hat RHSA-2011:0320-01 libcgroup 2011-03-03

Comments (none posted)

libtiff: code execution

Package(s):	libtiff	CVE #(s):	CVE-2011-0192
Created:	March 3, 2011	Updated:	June 27, 2011
Description:	From the Red Hat advisory: A heap-based buffer overflow flaw was found in the way libtiff processed certain TIFF Internet Fax image files, compressed with the CCITT Group 4 compression algorithm. An attacker could use this flaw to create a specially-crafted TIFF file that, when opened, would cause an application linked against libtiff to crash or, possibly, execute arbitrary code. (CVE-2011-0192)
Alerts:	Gentoo 201209-02 tiff 2012-09-23 Oracle ELSA-2012-0468 libtiff 2012-04-12 Debian DSA-2210-2 tiff 2011-06-25 CentOS CESA-2011:0392 libtiff 2011-04-14 CentOS CESA-2011:0318 libtiff 2011-04-14 Slackware SSA:2011-098-01 libtiff 2011-04-12 Fedora FEDORA-2011-3827 libtiff 2011-03-22 Debian DSA-2210-1 tiff 2011-04-03 SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01 CentOS CESA-2011:0392 libtiff 2011-03-31 SUSE SUSE-SR:2011:009 mailman, openssl, tgt, rsync, vsftpd, libzip1/libzip-devel, otrs, libtiff, kdelibs4, libwebkit, libpython2_6-1_0, perl, pure-ftpd, collectd, vino, aaa_base, exim 2011-05-17 Fedora FEDORA-2011-2540 libtiff 2011-03-03 Mandriva MDVSA-2011:043 libtiff 2011-03-08 Ubuntu USN-1085-1 tiff 2011-03-07 Pardus 2011-55 tiff 2011-03-04 CentOS CESA-2011:0318 libtiff 2011-03-02 Red Hat RHSA-2011:0318-01 libtiff 2011-03-02

Comments (none posted)

moin: cross-site scripting

Package(s):	moin	CVE #(s):	CVE-2011-1058
Created:	March 7, 2011	Updated:	October 10, 2011
Description:	From the CVE entry: Cross-site scripting (XSS) vulnerability in the reStructuredText (rst) parser in parser/text_rst.py in MoinMoin before 1.9.3, when docutils is installed or when "format rst" is set, allows remote attackers to inject arbitrary web script or HTML via a javascript: URL in the refuri attribute. NOTE: some of these details are obtained from third party information.
Alerts:	Gentoo 201210-02 moinmoin 2012-10-18 Ubuntu USN-1604-1 moin 2012-10-11 Debian DSA-2321-1 moin 2011-10-10 Fedora FEDORA-2011-2157 moin 2011-02-25 Fedora FEDORA-2011-2156 moin 2011-02-25

Comments (none posted)

moodle: multiple vulnerabilities

Package(s):	moodle	CVE #(s):
Created:	March 4, 2011	Updated:	June 16, 2011
Description:	From the Moodle release notes: MSA-11-0002 - Cross-site request forgery vulnerability in RSS block MSA-11-0003 - Cross-site scripting vulnerability in tag autocomplete MSA-11-0008 - IMS enterprise enrollment file may disclose sensitive information
Alerts:	Debian DSA-2262-1 moodle 2011-06-15 Fedora FEDORA-2011-2100 moodle 2011-02-24 Fedora FEDORA-2011-2101 moodle 2011-02-24

Comments (none posted)

proftpd: denial of service

Package(s):	proftpd-dfsg proftpd	CVE #(s):	CVE-2011-1137
Created:	March 9, 2011	Updated:	April 18, 2011
Description:	The proftpd FTP daemon suffers from an integer overflow in its SFTP module, enabling a denial of service attack.
Alerts:	Gentoo 201309-15 proftpd 2013-09-24 Fedora FEDORA-2011-5033 proftpd 2011-04-08 Fedora FEDORA-2011-5040 proftpd 2011-04-08 Slackware SSA:2011-095-01 proftpd 2011-04-05 Debian DSA-2185-1 proftpd-dfsg 2011-03-07

Comments (none posted)

pywebdav: SQL injection

Package(s):	pywebdav	CVE #(s):	CVE-2011-0432
Created:	March 3, 2011	Updated:	March 10, 2011
Description:	From the Debian advisory: It was discovered that python-webdav, a WebDAV server implementation, contains several SQL injection vulnerabilities in the processing of user credentials.
Alerts:	Fedora FEDORA-2011-2470 pywebdav 2011-03-02 Fedora FEDORA-2011-2460 pywebdav 2011-03-02 Debian DSA-2177-1 pywebdav 2011-03-02

Comments (none posted)

rubygem-actionpack: cross-site scripting/request forgery

Package(s):	rubygem-actionpack	CVE #(s):	CVE-2011-0446 CVE-2011-0447
Created:	March 7, 2011	Updated:	September 7, 2011
Description:	From the CVE entries: Multiple cross-site scripting (XSS) vulnerabilities in the mail_to helper in Ruby on Rails before 2.3.11, and 3.x before 3.0.4, when javascript encoding is used, allow remote attackers to inject arbitrary web script or HTML via a crafted (1) name or (2) email value. (CVE-2011-0446) Ruby on Rails 2.1.x, 2.2.x, and 2.3.x before 2.3.11, and 3.x before 3.0.4, does not properly validate HTTP requests that contain an X-Requested-With header, which makes it easier for remote attackers to conduct cross-site request forgery (CSRF) attacks via forged (1) AJAX or (2) API requests that leverage "combinations of browser plugins and HTTP redirects," a related issue to CVE-2011-0696. (CVE-2011-0447)
Alerts:	Gentoo 201412-28 rails 2014-12-14 openSUSE openSUSE-SU-2011:1305-1 ruby 2011-12-07 Debian DSA-2247-1 rails 2011-05-31 Fedora FEDORA-2011-2138 rubygem-actionpack 2011-02-24 Fedora FEDORA-2011-2133 rubygem-actionpack 2011-02-24

Comments (none posted)

scsi-target-utils: denial of service

Package(s):	scsi-target-utils	CVE #(s):	CVE-2011-0001
Created:	March 9, 2011	Updated:	July 12, 2011
Description:	The tgtd daemon in the scsi-target-utils package contains a double-free flaw which can be exploited to force a crash.
Alerts:	Fedora FEDORA-2011-8930 scsi-target-utils 2011-07-01 Fedora FEDORA-2011-8890 scsi-target-utils 2011-06-30 Ubuntu USN-1156-1 tgt 2011-06-21 CentOS CESA-2011:0332 scsi-target-utils 2011-04-14 Debian DSA-2209-1 tgt 2011-04-02 SUSE SUSE-SR:2011:009 mailman, openssl, tgt, rsync, vsftpd, libzip1/libzip-devel, otrs, libtiff, kdelibs4, libwebkit, libpython2_6-1_0, perl, pure-ftpd, collectd, vino, aaa_base, exim 2011-05-17 Red Hat RHSA-2011:0332-01 scsi-target-utils 2011-03-09

Comments (none posted)

seamonkey: arbitrary code execution

Package(s):	iceape, seamonkey	CVE #(s):	CVE-2010-0056
Created:	March 4, 2011	Updated:	March 21, 2011
Description:	From the Debian advisory: Christian Holler discovered buffer overflows in the Javascript engine, which could allow the execution of arbitrary code.
Alerts:	Debian DSA-2186-2 vimperator 2011-03-18 Debian DSA-2187-1 icedove 2011-03-09 Debian DSA-2186-1 iceweasel 2011-03-09 Debian DSA-2180-1 iceape 2011-03-03

Comments (none posted)

subversion: denial of service

Package(s):	subversion	CVE #(s):	CVE-2011-0715
Created:	March 4, 2011	Updated:	June 27, 2011
Description:	From the Debian advisory: Philip Martin discovered that HTTP-based Subversion servers crash when processing lock requests on repositories which support unauthenticated read access.
Alerts:	Gentoo 201309-11 subversion 2013-09-23 SUSE SUSE-SU-2011:0691-1 subversion 2011-06-27 SUSE SUSE-SU-2011:0692-1 subversion 2011-06-27 openSUSE openSUSE-SU-2011:0693-1 subversion 2011-06-27 CentOS CESA-2011:0327 subversion 2011-04-14 Pardus 2011-66 mod_dav_svn subversion 2011-04-08 Mandriva MDVSA-2011:067 subversion 2011-04-06 SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01 Ubuntu USN-1096-1 subversion 2011-03-29 openSUSE openSUSE-SU-2011:0238-1 subversion 2011-03-28 Fedora FEDORA-2011-2657 subversion 2011-03-05 Fedora FEDORA-2011-2698 subversion 2011-03-05 Slackware SSA:2011-070-01 subversion 2011-03-11 Red Hat RHSA-2011:0328-01 subversion 2011-03-08 Red Hat RHSA-2011:0327-01 subversion 2011-03-08 Debian DSA-2182-1 logwatch 2011-03-04 Debian DSA-2181-1 subversion 2011-03-04

Comments (none posted)

texmacs: privilege escalation

Package(s):	TeXmacs	CVE #(s):	CVE-2010-3394
Created:	March 7, 2011	Updated:	January 27, 2014
Description:	From the CVE entry: The (1) texmacs and (2) tm_mupad_help scripts in TeXmacs 1.0.7.4 place a zero-length directory name in the LD_LIBRARY_PATH, which allows local users to gain privileges via a Trojan horse shared library in the current working directory.
Alerts:	Gentoo 201401-27 texmacs 2014-01-25 Fedora FEDORA-2011-2146 TeXmacs 2011-02-24 Fedora FEDORA-2011-2127 TeXmacs 2011-02-24

Comments (none posted)

tiff: arbitrary code execution

Package(s):	libtiff	CVE #(s):	CVE-2011-0191
Created:	March 4, 2011	Updated:	June 27, 2011
Description:	From the CVE entry: Buffer overflow in LibTIFF in ImageIO in Apple iTunes before 10.2 on Windows allows remote attackers to execute arbitrary code or cause a denial of service (application crash) via a crafted TIFF image with JPEG encoding.
Alerts:	Debian DSA-2210-2 tiff 2011-06-25 Debian DSA-2210-1 tiff 2011-04-03 Mandriva MDVSA-2011:064 libtiff 2011-04-04 SUSE SUSE-SR:2011:005 hplip, perl, subversion, t1lib, bind, tomcat5, tomcat6, avahi, gimp, aaa_base, build, libtiff, krb5, nbd, clamav, aaa_base, flash-player, pango, openssl, subversion, postgresql, logwatch, libxml2, quagga, fuse, util-linux 2011-04-01 openSUSE openSUSE-SU-2011:0399-1 kernel 2011-04-28 Ubuntu USN-1085-2 tiff 2011-03-15 Ubuntu USN-1085-1 tiff 2011-03-07 Pardus 2011-55 tiff 2011-03-04

Comments (none posted)

wireshark: multiple DOS vulnerabilities

Package(s):	wireshark	CVE #(s):	CVE-2011-1139 CVE-2011-1140 CVE-2011-1141 CVE-2011-1142
Created:	March 9, 2011	Updated:	April 19, 2011
Description:	Wireshark suffers from denial-of-service vulnerabilities in its SMB, LDAP, and BER dissectors, and one which exploitable via a crafted pcap capture file.
Alerts:	Gentoo 201110-02 wireshark 2011-10-09 SUSE SUSE-SR:2011:007 NetworkManager, OpenOffice_org, apache2-slms, dbus-1-glib, dhcp/dhcpcd/dhcp6, freetype2, kbd, krb5, libcgroup, libmodplug, libvirt, mailman, moonlight-plugin, nbd, openldap2, pure-ftpd, python-feedparser, rsyslog, telepathy-gabble, wireshark 2011-04-19 openSUSE openSUSE-SU-2011:0347-1 wireshark 2011-04-18 CentOS CESA-2011:0370 wireshark 2011-04-14 Debian DSA-2201-1 wireshark 2011-03-23 CentOS CESA-2011:0370 wireshark 2011-03-22 Red Hat RHSA-2011:0370-01 wireshark 2011-03-21 Red Hat RHSA-2011:0369-01 wireshark 2011-03-21 Pardus 2011-57 wireshark 2011-03-21 Fedora FEDORA-2011-2620 wireshark 2011-03-04 Fedora FEDORA-2011-2632 wireshark 2011-03-04 Mandriva MDVSA-2011:044 wireshark 2011-03-08

Comments (none posted)

Kernel release status

The current development kernel is 2.6.38-rc8, released on March 7. Linus indicated that we should see the final 2.6.38 release in a week or so. "I would have been ok with releasing this as the final 38, but I'm going to be partially unreachable for several days next week, so I felt there was no point in opening the merge window yet. Also, we do have regressions. Some of them hopefully fixed here, but it won't hurt to give it another week." The short-form changelog is in the announcement, or see the full changelog for all the details.

Stable updates: 2.6.32.31, containing a single build fix, was released on March 3. It was followed by 2.6.32.32 and 2.6.37.3 on March 7; each of those releases contains a larger set of important fixes.

The 2.6.34.8-rt realtime patch set was released on March 4.

Comments (none posted)

Quotes of the week

-- Alan Cox

-- Tejun Heo

Comments (4 posted)

Removed directories and st_nlink

Al Viro was doing an audit of portions of the virtual filesystem layer when he noticed a bit of inconsistent behavior. If an application uses rename() to move one directory on top of another, the link count on the just-removed directory might not drop to zero. Some filesystems get the link count right, while others don't. Al saw that behavior as possibly confusing, so he put together a set of patches to fix things up.

Linus pulled the patches for 2.6.38-rc8, but wondered if it was really worthwhile. There are filesystems out there which do not track link counts at all, so applications cannot count on seeing correct link counts on removed directories. Any application which depends on such behavior is, he says, inherently buggy. Arguments that some applications do seem to care and that inotify will not work properly if the link count is wrong left him unmoved - but it does not matter that much, since the fixes went in anyway.

What may have been most surprising, even to experienced filesystem developers, is that the kernel allows the destructive renaming of one directory on top of another. A number of rules apply, but the POSIX standard explicitly specifies that such renames have to work. It has been that way since the early BSD days and, it does indeed work with Linux.

Comments (15 posted)

Protecting /proc/slabinfo

User-space access to internal kernel information is always something of a balancing act. That information can be useful for debugging or diagnosing problems, but it can also be used by attackers to simplify exploiting security vulnerabilities. At first glance, protecting /proc/slabinfo so that it can't be read by non-root users seems like a reasonable restriction to help reduce targeted heap corruption exploits, but as a patch to do so was discussed, it became clear that there are some more subtle issues to consider.

Memory for kernel objects is managed by the "slab" allocator, which allocates those objects into separate slabs based on their size. The kernel has several different slab allocators available, and users (or distributions) can choose the one they want to use when configuring the kernel. The exploits discussed in the thread were mostly aimed at the SLUB allocator because it mixes multiple object types of the same size into slabs.

The output from /proc/slabinfo lists the various slabs in use, the size of objects that they contain, the number of objects currently used in the slab, and so on. That information can be used to manipulate the heap layout in a way that's favorable to attackers.

Dan Rosenberg proposed changing the permissions of /proc/slabinfo to 0400, noting that "nearly all recent public exploits for heap issues rely on feedback from /proc/slabinfo to manipulate heap layout into an exploitable state". As he points out, normal users shouldn't really need access to that file, and on systems where that is desirable, the administrator can set the permissions appropriately.

While few argued that unprivileged users need access to the information (at least by default), there were immediate questions about whether shutting off the access would really be an obstacle for attackers. Matt Mackall put it this way:

That "10x" factor is important. If it were several order of magnitudes higher, it would be clearer that possibly inconveniencing some users is worthwhile. But making an attacker only work ten times harder may not be worth it as Mackall observes:

Mackall describes the basic idea behind these "heap smashing" attacks well, but Rosenberg gives a more detailed description of how they work:

So an attacker that can observe /proc/slabinfo can gain a great deal of information about slabs that would allow them to arrange the situation they need on the heap. But in the discussion, it became clear that there are other ways to gain some of that information (via observing /proc/meminfo for instance), though it turns out that an attacker can rely on probability to arrange objects in the "right" order.

One could, as Mackall suggested, pre-allocate a large number of objects such that a new page is allocated to the slab. The contents of that page are then largely under the control of the attacker, so freeing one of those objects and allocating the other kind will very likely result in the needed arrangement.

That led Pekka Enberg to propose a patch that would randomize the object layout within a slab. The idea is that attackers couldn't depend on the current sequential allocation of objects in the slab, as the free list in a new slab would be in a random order. When freeing one object and then allocating another, there would be no guarantee that the two would be sequential. That approach, too, falls by the wayside because of probability.

Even with a randomized slab, an attacker can half fill the slab page with overrunnable objects, then allocate an exploitable object; it will then have a roughly 50% chance of being in the right place. One could also fill the slab page with overrunnable objects, then free an object—or every tenth object. The holes left behind will have a high probability being in the right place. Essentially, Mackall and others in the thread showed that the current attacks using /proc/slabinfo output were insufficiently imaginative.

Mackall noted that the real underlying problem is that it is too easy for programmers to copy the wrong amount of data from user space (which is how most of these object overruns occur). He suggested that a copy_from_user() interface that was harder to get wrong might help reduce these kinds of problems:

There was general agreement that better interfaces should be added to reduce these kinds of problems. Alan Cox mentioned that Arjan van de Ven had created some "copy_from_user validation code [that] already does verification checks on the copies using gcc magic". While Rosenberg is still interested in pursuing the /proc/slabinfo protection along with Enberg's slab randomization patch, it's not clear that there will be much support for it from other kernel developers. Given that it imposes a performance penalty along with potentially inconveniencing users, without any real benefit, it may be rather hard to sell.

Comments (6 posted)

Improving ptrace()

The ptrace() system call is rarely held up as one of the better parts of the Unix interface. This call, which is used for the tracing and debugging of processes, is gifted with strange semantics (it reparents the traced process to the tracer), numerous interface warts, and occasionally unpredictable behavior. It is also hard to implement within the kernel; there are few developers who are willing to get into the depths of the ptrace() implementation. So it's not surprising that there has been occasional talk of simply replacing ptrace() with something better; see this 2010 article for a description of one such discussion.

While some developers think that ptrace() is beyond repair, Tejun Heo disagrees. To back that up, he has posted a set of proposals for the improvement of the interface, saying:

The bulk of the "love and attention" Tejun means to apply is addressed at the interaction between tracing and job control. In an untraced process, job control is used by the kernel and the shell to stop and restart processes, possibly moving them between the foreground and the background. Adding tracing to the picture confuses things for a number of reasons. For example, reparenting the traced process deprives the real parent of the ability to get notifications when that process is stopped or started. There are also some strange internal transitions between the TASK_STOPPED and TASK_TRACED states which lead to unpredictable and sometimes surprising behavior. For example, a task which is running under strace can be stopped with ^Z as usual, but the shell will be unable to restart it.

Tejun has a series of concrete proposals to improve the situation. The first of these is that a traced process should always, when stopped, be in the TASK_TRACED state. The current strange transitions between that state and TASK_STOPPED would go away. He would fix things so that notifications when a process stops or starts would always go to the real parent, even when a process has been reparented for tracing. Some edge cases, such as what happens when a traced process is detached, would be fixed so that process's behavior matches the untraced case.

To fix the "can't start a stopped, traced process" problem, Tejun would further enshrine the rule that the tracing process has total control over the traced process's state. So it's up to the tracer to start a stopped process if the shell wants that done. Currently, tracers have no way to know that the real parent has tried to start a stopped process, so a notification mechanism needs to be added. That would be done by extending the STOPPED notification that can currently be obtained with one of the variants of the wait() system call.

Finally, Tejun would like to fix the behavior of the PTRACE_ATTACH operation, which attaches to a process and sends a SIGSTOP signal to put it into the stopped state. The signal confuses things, and the stopped state is undesirable; it is not really possible, though, to change the semantics of PTRACE_ATTACH in this way without breaking applications. So he would create a new PTRACE_SEIZE operation which would attach to a process (if it's not already attached) and put the process immediately into the TASK_TRACED state.

These changes, Tejun thinks, are enough to turn ptrace() into something rather more predictable and civilized. He'd like to go forward into the implementation with a 2.6.40 target for merging. In the following discussion, it seems that most developers agree with these changes, modulo a quibble or two. The one big exception was Roland McGrath, who has done a lot of work in this area. Roland has some different ideas, especially with regard to PTRACE_SEIZE.

Roland's alternative to PTRACE_SEIZE (if it can truly be called an "alternative," having been suggested first) is to add two new commands: PTRACE_ATTACH_NOSTOP and PTRACE_INTERRUPT. The former would attach to a process but not change its running state in any way, while the latter would stop the process and put it into the TASK_TRACED state. He sees a number of advantages to this approach, including the ability to trace a process without ever stopping it. There are cases (strace comes to mind) where there is no need to stop the process; avoiding doing so allows the process to be traced while minimizing the effects on its behavior.

Roland also foresaw a variant of PTRACE_INTERRUPT which would only stop a process when it's running in user space. That would avoid the occasional "interrupted system call" failure that current tracing can cause. He also worries about what happens when PTRACE_SEIZE is, itself, interrupted; handling that situation in a way that supports the writing of robust applications, he says, would be hard. Finally, he raises the issue of scalability; he does not think that PTRACE_SEIZE will work well for the debugging of highly threaded applications. In summary, he said:

Unfortunately, it seems that Roland is changing jobs and stopping work in this area, so his thoughts may carry less weight than they normally would have. As of this writing, there have been few responses to his post; Tejun has mostly dismissed Roland's concerns. Tejun has also posted a patch series implementing parts of his proposal, but not, yet, PTRACE_SEIZE. The uncontroversial parts of this work will almost certainly be merged; how PTRACE_ATTACH will be fixed in the end remains to be seen.

Comments (none posted)

Delaying the OOM killer

The out-of-memory (OOM) killer is charged with killing off processes in response to a severe memory shortage. It has been the source of considerable discussion and numerous rewrites over the years. Perhaps that is inevitable given its purpose; choosing the right process to kill at the right time is never going to be an easy thing to code. The extension of the OOM killer into control groups has added to its flexibility, but has also raised some interesting issues of its own.

Normally, the OOM killer is invoked when the system as a whole is catastrophically out of memory. In the control group context, the OOM killer comes into play when the memory usage by the processes within that group exceeds the configured maximum and attempts to reclaim memory from those processes have failed. An out-of-memory situation which is contained to a control group is bad for the processes involved, but it should not threaten the rest of the system. That allows for a little more flexibility in how out-of-memory situations are handled.

In particular, it is possible for user space to take over OOM-killer duties in the control group context. Each group has a control file called oom_control which can be used in a couple of interesting ways:

• Writing "1" to that file will disable the OOM killer within that group. Should an out-of-memory situation come about, the processes in the affected group will simply block when attempting to allocate memory until the situation improves somehow.

• Through the use of a special eventfd() file descriptor, a process can use the oom_control file to sign up for notifications of out-of-memory events (see Documentation/cgroups/memory.txt for the details on how that is done). That process will be informed whenever the control group runs out of memory; it can then respond to address the problem.

There are a number of ways that this user-space OOM killer can fix a memory issue that affects a control group. It could simply raise the limit for that group, for example. Alternatives include killing processes or moving some processes to a different control group. All told, it's a reasonably flexible way of allowing user space to take over the responsibility of recovering from out-of-memory disasters.

At Google, though, it seems that it's not quite flexible enough. As has been widely reported, Google does not have very many machines to work with, so the company has a tendency to cram large numbers of tasks onto each host. That has led to an interesting problem: what happens if the user-space OOM killer is, itself, so starved for memory that it is unable to respond to an out-of-memory condition? What happens, it turns out, is that things just come to an unpleasant halt.

Google operations is not overly fond of unpleasant halts, so an attempt has been made to find another solution. The outcome was a patch from David Rientjes adding another control file to the control group called oom_delay_millisecs. Like oom_control, it holds off the kernel's OOM killer in favor of a user-space alternative. The difference is that the administrator can provide a time limit for the kernel OOM killer's patience; if the out-of-memory situation persists after that much time, the kernel's OOM killer will step in and resolve the situation with as much prejudice as necessary.

To David, this delay looks like a useful new feature for the memory control group mechanism. To Andrew Morton, instead, it looks like a kernel hack intended to work around user-space bugs, and he is not that thrilled by it. In Andrew's view, if user space has set itself up as the OOM handler for a control group, it needs to ensure that it is able to follow through. Adding the delay looks like a way to avoid that responsibility which could have long-term effects:

Andrew would rather see development effort put into fixing any kernel problems which might be preventing a user-space OOM killer from doing its job. David, though, doesn't see a way to work without this feature. If it doesn't get in, Google may have to carry it separately; he predicted, though, that other users will start asking for it as usage of the memory controller increases. As of this writing, that's where the discussion stands.

Comments (36 posted)

Beyond Firefox 4.0: Handling an accelerated development cycle

Firefox 4.0 has been delayed a number of times, but looks to finally be on the verge of release. With 4.0 out the door, the Mozilla developers will be pursuing a quarterly release cycle that would see Firefox 5, 6, and 7 released by the end of 2011. For Windows and Mac users, accelerated releases just mean they'll see more frequent updates. For Linux users, and for distribution vendors, quarterly releases may pose a few challenges.

Many have complained that the six-month release cycle followed by Ubuntu and Fedora is too brisk, but the proposed Firefox release plan will be even more aggressive — averaging a major release each quarter. This means that it's likely that Mozilla will release two major Firefox updates during a distribution development cycle. To be sure, the releases will not be as significant as the Firefox 4.0 update. Mozilla plans to shift the way that it approaches major releases so that there will be fewer features per release, but continual improvements.

This is fine for users who get their updates directly from Mozilla, but it looks likely to pose a challenge for Linux distributions and users who want to run current Firefox releases as part of the distribution. Most distributions have a policy of providing only security updates for packages after the distribution has shipped.

Firefox has already been an outlier in this regard. For desktop Linux releases, Firefox is a key component — and Linux desktop users typically don't want to run an aging or obsolete browser. Firefox's major releases often don't fit well with Linux distribution release cycles — particularly since Mozilla has been known to slip release dates by rather a lot. Firefox 4.0 is a prime example of this, having originally been scheduled for an October release.

In consideration for users, distributions have made special exemptions to update policies by working with Firefox betas during the development cycle and then shipping updates to bring Firefox up to the final release. How will they handle major bumps to Firefox that happen at a much faster pace?

Right now, users on released versions of openSUSE, Ubuntu, and Fedora have the option of installing major Firefox updates from add-on repositories. The openSUSE Project has its Mozilla repository, which allows users to track major updates for stable openSUSE releases. (This should also be suitable for users of SUSE Linux Enterprise Desktop.) Users can also track openSUSE Tumbleweed and receive the stable updates for pretty much all of the major packages, if they're so inclined. Ubuntu currently offers a PPA for new versions of Firefox, and Fedora has the "Remi" repository.

These solutions are fine for users who are familiar with advanced package management. (LWN readers may not consider adding a PPA or RPM repository "advanced," but many users would.) But all of these require users to seek out and add package repositories, which may have been OK when Firefox major releases were spread out by more than a year — but not so much when they become a quarterly affair.

How will the major distributions handle this? Fedora is unlikely to issue major Firefox updates after release, at least for the time being, through the regular update channel. Fedora's Christopher Aillon, who is responsible for the official Firefox packages, says that this is due to the number of packages that depend on the Firefox platform (XULRunner). He adds that "speeding things up won't help that", but that the situation may change as more packages depend on Webkit instead of Firefox/XULRunner "but it's not on the immediate radar."

What about security fixes? Aillon says that it might involve more backporting of security patches, but "it will be nothing new to us. We know the codebase very well and I'm confident that Fedora's packages will remain stable and secure."

As for openSUSE and future stable releases, it's not decided yet how the project will handle Firefox updates. openSUSE's Wolfgang Rosenauer says that "I haven't discussed these plans deeply yet since I was busy wrapping up Firefox 4 for 11.4. Actually I guess the whole Mozilla project was [wrapping up Firefox 4.0] and most of the planning and discussion will take place from now on."

According to Canonical's Jason Warner, users can continue using the PPA to grab major updates of Firefox. As long as the version of Firefox shipped with an Ubuntu release is receiving security fixes, Ubuntu will stay with that release. However, Warner says that Ubuntu will ship major releases of Firefox as an update if Mozilla stops supporting the earlier release. For example, "We will continue updating FF 3.6 for 10.04 users as long as Mozilla supports that release (typically 6 months after a major release). Once Mozilla stops supporting 3.6 we will update to the latest stable release, whichever number that is at the time."

It looks like Red Hat will make newer releases of Firefox available for desktop/workstation users of Red Hat Enterprise Linux (RHEL). Actually, the company has been handling updated releases of Firefox for some time in its older versions. I pinged Red Hat PR and they responded that Firefox 3.6.x is already being shipped for RHEL 4, 5, and 6. According to Red Hat the plan is to "stay as close as possible to the latest Mozilla release, while at the same time ensuring we provide customers with a stable and secure web browser."

This is largely uncharted territory for distributions and Mozilla. Google's Chrome browser and Chromium project have been doing rapid-fire releases for some time, but have largely bypassed the distributions. Google provides its own packages for Linux users, and only Ubuntu packages Chromium in the default repositories. It would be nice if Mozilla provided native packages for Linux users as well, especially since Mozilla only offers 32-bit packages as the official build for Linux users.

If Mozilla manages to keep to its schedule for 2011 it will be interesting to see how it shakes out for distributions and how they deal with the new development cycle. It will likely require creating some exceptions to policies on shipping major updates rather than just security releases, or perhaps rethinking how releases are handled in general.

Comments (28 posted)

Distribution quotes of the week

-- Stefano Zacchiroli runs for another term as Debian Project Leader

-- Paul Flo Williams

-- Bruno Lowagie

-- PJ Weisberg

Comments (none posted)

CentOS 4.9 released

CentOS 4.9 is available for i386 and x86_64 release of CentOS-4.9. This release includes all updates through March 1, 2011. "This is the last expected set of changes to add new functionality to the CentOS 4. We will continue to provide security updates and bug fixes for CentOS 4 until its End-of-Life scheduled for February 29, 2012." The project has also given the 1 year notification for the end of life for CentOS 4.

Full Story (comments: 1)

Announcing the release of Fedora 15 Alpha

The Fedora 15 "Lovelock" Alpha release is available for testing. "The Alpha release contains all the beefy features of Fedora 15 in a form that anyone can help test. This testing, guided by the Fedora QA team, helps us target and identify bugs. When these bugs are fixed, we make a Beta release available. A Beta release is code-complete, and bears a very strong resemblance to the third and final release. The final release of Fedora 15 is due in May."

Full Story (comments: 30)

Foresight Linux 2.5.0 RC

Foresight Linux 2.5.0 release candidates are available in GNOME, KDE, and Xfce editions.

Comments (none posted)

Gentoo Linux LiveDVD 11.0 released

For those who would like to play with Gentoo but don't feel like spending a few days compiling it: the 11.0 LiveDVD release is now available. There is a wide variety of software available; see the announcement for details. "Desktop environments and window managers include: KDE SC 4.6, GNOME 2.32, Xfce 4.8, Enlightenment 1.0.7, Openbox 3.4.11.2, Fluxbox 1.3.1, XBMC 10.0 and more."

Comments (12 posted)

Some MeeGo architecture changes announced

The MeeGo project has announced some changes in response to "the events of the last few weeks". In particular, they are moving (back) to SyncEvolution from Buteo, moving contact storage to Evolution Data Server, and making some changes to the security framework. "In the long-term, we will re-evaluate the direction we are taking with MeeGo security with a new focus on *End-User Privacy*. While we do not intend to immediately remove the security enabling technologies we have been including in MeeGo, all security technologies will be re-examined with this new focus in mind." We will probably see more of this type of change as MeeGo figures out how things will go in Nokia's absence.

Full Story (comments: 3)

Scientific Linux 6.0 released

Scientific Linux (SL), which is a re-packaging of Red Hat Enterprise Linux geared toward scientific users, has released SL 6.0. "SL is a Linux release put together by Fermilab, CERN, and various other labs and universities around the world. Its primary purpose is to reduce duplicated effort of the labs, and to have a common install base for the various experimenters." A brief look at SL 6.0 is available at the Symmetry magazine breaking news site (which is, in turn, pulled from the Fermilab Today site). From that article: "For more than 12 years, Fermilab has supplied thousands of individuals in the scientific community with the operating system that forms the foundation for their exploration of the universe's secrets. The Linux operating system produced at Fermilab enabled the laboratory, and other high-energy physics institutions to build large physics data analysis clusters using affordable, commercially available computers."

Comments (30 posted)

Slackware 13.37 rc1 released

Slackware 13.37 release candidate 1 has been announced for x86 and x86_64. From the March 9 changelog entry. "Hey folks, I think it's time for Slackware 13.37 (hopefully this helps make up for our lack of code names) release candidate 1! After a lot of testing and consideration, we've decided to go with the recently released 2.6.37.3 Linux kernel which seems to work best for X, contains support for Speakup, and looks like a better kernel branch to be using as we move forward. Please test so we can have a stable release soon. :-)"

Comments (3 posted)

Ubuntu Natty Alpha 3 Released

Ubuntu has released the third alpha for "Natty Narwhal" aka 11.04. Some of the new packages in this release include LibreOffice 3.3.1, Unity 3.6.0, Linux Kernel 2.6.38-rc6, and Upstart 0.9.

Full Story (comments: none)

Debian wins at the Linux New Media Awards 2011

The Debian Project won two awards this year's Linux New Media Awards, presented during CeBIT. The first was for "Best Open Source Server Distribution" and the second for the project's "Outstanding Contribution to Open Source/Linux/Free Software".

Full Story (comments: none)

bits from the DPL: squeeze aftermath

Debian Project Leader Stefano Zacchiroli has a few bits about Debian's relationship with the FSF, talks and interviews, Debian vs DebConf, and several other topics. "Wheezy is open, meaning you can now break your pet packages :-) (not). If you haven't yet discussed with other fellow developers your amazing plans for Wheezy, I suggest you stop reading this mail, go start a *huge* thread on your favorite Debian development mailing list to discuss those plans, and get back once you're satisfied with the result."

Full Story (comments: none)

Update on FUDCons in 2011

Jared K. Smith has some FUDCon (Fedora Users and Developers Conference) announcements. "Planning is in full swing for FUDCon Panama in May, and it's time for the FUDCon planning team to begin evaluating subsidy requests. The deadline for the first round of travel subsidies is the end of the day (UTC time) on March 14th, and the FUDCon planning team will be meeting on March 15th to evaluate those requests." Future FUDCons: the bidding for FUDCon EMEA 2011 will close after March 15th and bidding is now open for FUDCon North America in late 2011 or early 2012.

Full Story (comments: none)

Welcome to the new Jolicloud!

Jolicloud founder Tariq Krim takes a look at the future for Jolicloud and the soon to be released Joli OS 1.2. "Following up on our previous blog posts on the new direction for Jolicloud and the Joli OS 1.2 feature list, we'd like to share with you some of the features that are available in the new Jolicloud desktop and Joli OS 1.2."

Comments (none posted)

Distribution newsletters

• Debian Misc. Developer News #26 (March 10)
• DistroWatch Weekly, Issue 395 (March 7)
• Fedora Weekly News Issue 265 (March 2)
• openSUSE Weekly News, Issue 165 (March 5)

Comments (none posted)

Linux Leaders: Debian and Ubuntu Derivative Distros (Datamation)

Bruce Byfield covers a wide variety of distributions that descend from Debian. "One of the oldest derivatives is Knoppix, which is also a pioneer of Live Media -- CDs or DVDs from which you can boot a computer without accessing the hard drive for secure computing or for demoing software. For many, Knoppix remains an essential tool, especially as a rescue disk. In fact, Knoppix is so popular that it has evolved its own derivatives."

Comments (none posted)

Linux Leaders, Part II: Fedora and Red Hat Derivative Distros (Datamation)

The second part of Bruce Byfield's look at Linux Leaders covers Fedora and Red Hat derivatives. "Fedora, the successor to Red Hat Linux and perhaps the most influential distribution prior to 2000, is consciously produced as the source for other distributions. In many of its releases, it is among the most innovative distros, releasing new software developed in co-operation with upstream projects. Development is more or less continuous within its Rawhide repository, with stable releases produced every six months."

Comments (none posted)

Kororaa GNU/Linux is back (ITWire)

ITWire covers Kororaa GNU/Linux, a little known distribution that started out as an easy way to install Gentoo, and has more recently switched to a Fedora base. The third beta of Kororaa 14 was recently released.

Comments (none posted)

Yocto and OpenEmbedded Combine Forces: What Does It Mean? (Linux.com)

Over at Linux.com, Nathan Willis digs a little deeper into the combination of Yocto and OpenEmbedded. "Thus, this week's announcement does not amount to a significant shift in the underlying technology, but it does formally align two projects that already had similar goals. As a result of the merger, Yocto will now support an "OpenEmbedded Core" that can serve as a foundation for building an embedded Linux distribution. The OpenEmbedded Core consists of base-layer recipes and files, on top of which the developer would stack other components, including other Yocto utilities, hardware-specific drivers, and custom user interface or application code."

Comments (none posted)

openSUSE 11.4 articles

openSUSE 11.4 is scheduled for release on March 10, just after press time for LWN. In the meantime the openSUSE news team has articles about GNOME on openSUSE 11.4, openSUSE 11.4 and KDE and the inclusion of LibreOffice.

Comments (none posted)

Shuttleworth: Next after Natty?

No doubt everybody was anxious to know what the next Ubuntu release would be called; Mark Shuttleworth has now ended the suspense. "What we want is something imaginative, something dreamy. Something sleek and neat, too. Something that has all the precision of T S Elliot's poetry, matched with the 'effable ineffability' of our shared values, friendship and expertise. Something that captures both the competence of ubuntu-devel with the imagination of ayatana. Which leads us neatly to the Oneiric Ocelot."

Comments (30 posted)

Thomas: That's it, we're quitting

Matthew Paul Thomas posts on the "Canonical Design" site about Canonical's intent to eliminate the "quit" button in applications. "The 'Quit' command in applications today is a relic from the days when the original Macintosh had no hard disk and couldn't multitask. Modern applications have made this command increasingly annoying. Fortunately, though, modern PCs have also made it increasingly unnecessary. Mobile operating systems have, for the most part, eliminated the 'Quit' command completely. In Ubuntu, the messaging and sound menus will help us do the same."

Comments (143 posted)

SCALE: Phoronix launches OpenBenchmarking

Michael Larabel and Matthew Tippett of Phoronix took the wraps off of their latest project at SCALE 9x in late February. Named OpenBenchmarking, the project builds on the Phoronix Test Suite to allow everyday users to run a series of tightly controlled hardware benchmarking tests, then upload the results to a public database. The data can then be correlated with automatically-harvested details about the operating system and software stack. The practical upshot is that other users can browse in the collected data for a far more comprehensive look at individual system components.

The talk was entitled "Making More Informed Linux Hardware Choices," which succinctly sums up Larabel and Tippett's primary use-case for OpenBenchmarking: a user is shopping for a new component, and consults the OpenBenchmarking database to find detailed, statistically significant reports on compatibility and performance. They introduced the topic by positing that Linux-using hardware shoppers always begin by asking "does it work?" (a question for which consulting Google and reading discussion forums is generally the only way to find an answer), followed by "how fast is it?" (a question on which there are even fewer solid answers).

In the past, they said, commercial distributions have published "hardware compatibility lists," but these tended to be minimal, well behind the cutting edge, and often only tested for bare-bones functionality. For example, a graphics card might be published on a distribution's hardware compatibility list if it functions on servers using the VGA driver, but that is unlikely to help a home desktop user who really wants to know if hardware acceleration works for 3D games and video playback. The performance data available on the web, when it does address Linux, either does not specify the test conditions well enough to be helpful, or it is completely anecdotal.

The Phoronix Test Suite is a test framework that can run a wide selection of benchmarking tests, from those that test raw graphics, memory, and disk performance, to those that test specific CPU features. Phoronix is very GPU-centric, and thus many of the tests focus on graphics cards, but as a whole the test suite can be used to run tightly-controlled tests on just about any performance factor, and gather a detailed system profile to accompany it. The profile even includes system logs, to flag extraneous events that might have affected the test.

In broad strokes, OpenBenchmarking is designed to provide these missing pieces of the hardware shopping puzzle. Its creators, naturally, have built it around their own benchmarking test suite, but the same essential service could be developed around any collection of benchmarking tests. OpenBenchmarking tries to add to that basic functionality by profiling the system on which the test was run, including the full complement of hardware on the system, distribution and version, and the precise kernel, video driver, and X server options used. Site users can fine-tune their comparisons to closely match their own systems, or to compare results for a particular test across some orthogonal factor (to see, for example, whether Ubuntu or openSUSE produces the higher frame rate for a particular graphics test, or faster builds on a particular compiler test).

The site also offers some more complex features, such as linking to test results found on external sites, comparing results for multiple components in parallel, and a "product finder" search tool that whittles down a particular hardware buying decision with a sequence of questions. At the moment, the product finder can only help you search for a CPU, motherboard, or graphics card, but the parallel comparison tool has no limitations. You can select any test (MP3 encoding, Apache stress testing, raytracing, etc), then add any of the results to your custom comparison, and the site will generate graphs pitting them against each other head-to-head — and almost instantaneously, to boot.

Data, data, data

The team has also developed its own visualizations for the test results, most notably "heatmaps" of histogram data. The concept is that traditional bar-graph style histograms all begin to look alike when there are too many data points, so OpenBenchmarking displays "bird's eye" views of the graph instead, where higher numbers are rendered as darker pixels, and lower numbers as lighter pixels. I am not persuaded that heatmaps are a substantially different perspective (no pun intended), but during the demo Larabel and Tippett showed some large data sets where it was easier to pick out outliers in a heatmap than on a bar graph. For their part, all of the graphs are easy to read: all axes are labeled, scores' histograms are drawn to size but also labeled with the precise measurement, and each graph includes a key indicating the standard error (for the statisticians) and whether higher or lower numbers are best (for the non-statisticians).

Presenting the data visually is only half of the battle, though. The OpenBenchmarking site is designed to make it easy to "drill down" in any direction from a test result page. Each test result that you see comes with hyperlinked tables, so that you can (for example) click on the hard disk in the "System Information" header, and access all tests in the database that include that particular model, even if the test you were looking at had nothing to do with disk performance. During the talk, Larabel and Tippett said that the components database combines data for re-branded products, which is a bigger issue for graphics cards than some other product types, and should make the data sets more usable for component-hunters.

You can add additional statistical measurements to each results page or filter out some results if that better suits your purpose. Test pages allow users to leave comments (although comments are scarce for now), as well as to save a direct link to any custom comparison, alleviating the need to re-add the individual factors on a subsequent visit. Finally, if you have the Phoronix Test Suite package installed on your system, you can click a link on every page to launch the selected test on your own machine.

Direct data export and a public query API are slated to come to the service later this year, as are some additional measurements and features. The speakers said they would be adding periodic "general community performance" snapshots that summarized all recent tests, and a "virtual build-a-system" tool that lets users define a system performance profile, and find which combinations of components will let them achieve it (and at which price points).

They also mentioned a "Phoronix Certification and Qualification Suite" (PCQS) for formal performance validation, which is a peculiar choice considering that they had harsh words for the certifications provided by OEMs and software vendors. High on the list of problems they cited with other certification programs was that they are invented to further the interests of either the hardware vendor or the software maker, so perhaps the PCQS is going to be more trustworthy because Phoronix itself is neither. We will have to wait and see when the details are announced.

In the audience question-and-answer portion of the talk, the two explained some of the steps they take to prevent outliers from corrupting overall performance data, and to prevent device manufacturers from trying to "game" the system by uploading slanted results in hopes of bolstering their products' reputation. There is active monitoring of the data set, but the long-term reliability seems to come from crowdsourcing — i.e., if particular numbers seem too good to be true and are un-reproducible, site readers will notice them and raise alarms.

Drilling in

You can sample the OpenBenchmarking service for yourself today. The site claims more than 480,000 components and more than 74,000 systems, resulting in more than 37,000 test result files. I'm not sure exactly how those numbers fit together, but there are clearly enough data points to see what OpenBenchmarking is capable of.

From a usability standpoint, OpenBenchmarking throws you right into the deep end. From the home page you can jump right into the top searches, top hardware, and top software, and from the sidebar immediately click through to the most recent tests, the most recent test suites, and the most recent test profiles.

But you might need to spend a few minutes reading through the site documentation to get a grasp of the difference between a test suite and a test profile before you do so. To be frank, I am not entirely clear I grasp the definitions; a test suite is described as "an XML file that defines tests and suites for which the Phoronix Test Suite, or other OpenBenchmarking.org schema-compliant test clients, are able to execute in a defined, pre-configured form", while a test profile "is comprised of an XML file and set of scripts that define how the Phoronix Test Suite or other OpenBenchmarking.org schema-compliant test clients interact with an individual test and provide abstraction for all relevant test information". Got it?

Fortunately, digging in to find actual performance numbers is easier. Wherever you see a component, an operating system, or the name of a test, you can click directly on it to bring up all of the OpenBenchmarking database numbers related to it. In fact, almost every element on every page seems to be a clickable link, including many that are not distinguished from ordinary inactive text. There are some layout problems, such as the way the "System Information" header is embedded in a horizontally-scrollable table that doesn't fit into the main content column, and uses comically-wide columns of its own that are sized to fit long product names onto a single line.

Some elements of the test result pages need further explanation. For example, each graph has a tiny hyperlinked "T" in the bottom right-hand corner, which when clicked turns the graph into a table, but this feature is not documented anywhere, and on a page filled with identical graphs, it is easily lost.

All of those are cosmetic design issues. But it is also frequently confusing that each user who uploads a set of test results evidently gets to assign a custom name to his or her specific system. Here's why. For an individual, the best way to differentiate between two systems being tested is often to name them according to the major piece of hardware being considered (such as two different graphics cards). Once those results are uploaded to the public database, though, the results are accessible through every dimension of the system configuration. This means you can end up looking at a CPU benchmark test where the data series are labeled with graphics card names, because that is what the original uploader assigned to their test set-ups.

It is also extremely easy to head off on a tangent when browsing through search results, when narrowing down the search results might be better. For instance, you can click on a component, such as the Intel Core 2 Quad Q6600 processor, and get a page pulling all of the test sets that involve it out of the database. The top of the page lists the various operating systems, kernels, and motherboards used in the database's Q6600 tests. But clicking on any of those links does not filter the existing results to include just the clicked-on option: it leads you off onto the start page devoted to that option.

Benchmarks gone wild

In general, OpenBenchmarking does contain a wealth of data, but it needs work on exposing that data in an easy-to-navigate form. Maximizing hardware performance is a hobby with intense appeal to some Linux users and none whatsoever to others, so perhaps OpenBenchmarking's current usability is a good fit for the speed-obsessed. What is more interesting to the broader Linux community are the hints that Larabel and Tippett dropped about ways the total data set can be mined and mashed-up in the future.

For example, they discussed the possibility that the data could be used to automatically spot regressions in system software, so that OpenBenchmarking might detect a bug in the new release of a video card driver that slipped under the radar during testing. Or the data could track performance over a long period of time, and discover that a Linux distribution has been getting gradually slower at certain tasks, which might prompt users to pick a different distribution for their long-term deployment.

For these use cases, we will likely have to wait for additional features to roll out on the OpenBenchmarking site. System tweakers will generate and upload most of the data to OpenBenchmarking — that data is more useful to them in the short term, while it will be most enlightening to others only when mashed-up and transformed.

Comments (1 posted)

Quotes of the week

-- Matthew Garrett

-- Máirín Duffy

-- Tom Christiansen

-- Lennart Poettering

Comments (15 posted)

Chrome 10 released

Google has announced the release of version 10 of the Chrome browser. New stuff includes better JavaScript performance, GPU-accelerated video, and a number of security features including better plugin blocking and sandboxing of the Flash plugin (on Windows only, alas).

Comments (30 posted)

LyX version 2.0.0 (release candidate 1)

The first LyX 2.0.0 release candidate is out; now would be a good time for LyX users to test things out and find the last remaining bugs. (LWN looked at LyX 2.0 last November).

Full Story (comments: none)

PacketFence 2.1.0 released

Version 2.1.0 of the PacketFence network access control system is available. Changes in this release include support for a few new routers, a new configuration validation interface, JavaScript-based network access detection, improved desktop Linux client support, and more.

Full Story (comments: none)

PyNSource 1.5 released

PyNSource is a "Python reverse engineering" tool which generates UML diagrams from Python source. The 1.5 release adds Python 2.6 and 2.7 compatibility, improved menus, and more.

Full Story (comments: none)

RPM 4.9.0 released

Version 4.9.0 of the RPM package manager is out. Improvements include a refusal to install packages which are obsoleted by other, already installed packages, the ability to install self-conflicting packages, more readable -i output, additional query options, and more; see the release notes for details.

Full Story (comments: none)

Development newsletters from the last week

• Caml Weekly News (March 8)
• LibreOffice development summary (March 9)
• Linux Audio Monthly Roundup (February)
• PostgreSQL Weekly News (March 6)

Comments (none posted)

A restart for RandR 1.4 (The H)

The H has a brief report on the status of X RandR (Resize and Rotate) 1.4 in light of it being pulled from X.Org 1.10 at the last moment due to concerns about the protocol. "Version 1.4 of Resize and Rotate promises per-CRTC pixmaps and the possibility of support from NVIDIA's proprietary Linux graphics driver. At present, Linux users with NVIDIA cards (NVIDIA is estimated to hold roughly a 30% share of the graphics market) must use the proprietary NVIDIA settings utility. With NVIDIA's driver with RandR support, screen resolution could be adjusted in a more integrated fashion from the desktop."

Comments (4 posted)

FSF announces new executive director

The Free Software Foundation (FSF) has announced the appointment of John Sullivan as its new executive director. "The appointment follows the departure of Peter T. Brown, who has been the Foundation's executive director since 2005. Brown shares his reflections on the change in a blog post at http://www.fsf.org/blogs/community/peterb."

Full Story (comments: none)

Nokia sells its Qt licensing business to Digia

Nokia has announced that it is selling its Qt commercial licensing business to Digia. "We want to emphasize our long-term commitment to Qt. Nokia will drive Qt developments in support of our business needs and our investments in community building, marketing and R&D will continue to benefit all members of the Qt community. By introducing the up-coming open governance model we will also enable other companies, such as Digia, to more easily contribute to Qt, which will enrich Nokia investments in Qt and benefit and grow the Qt community as a whole."

Comments (29 posted)

Novell Reports Financial Results for First Fiscal Quarter 2011

Novell has announced its financial results for the first fiscal quarter of 2011. "For the quarter, Novell reported net revenue of $191 million. This compares to net revenue of $202 million for the first fiscal quarter of 2010. GAAP income from operations for the first fiscal quarter of 2011 was $12 million. This compares to GAAP income from operations of $21 million for the first fiscal quarter of 2010."

Comments (none posted)

15 Must-Have Linux Desktop Apps (Datamation)

Matt Hartley looks at 15 desktop applications for the Linux desktop. "Recently it was brought to my attention that all the desktop Linux hoopla in the world doesn't mean squat without compelling applications to get the end user interested. To address this need, I've rounded up fifteen powerful Linux applications that reflect the best that Linux has to offer the desktop user, both in and out of the enterprise environment."

Comments (3 posted)

Commitment to Open (Red Hat News)

Red Hat CTO Brian Stevens responds to criticism of Red Hat's decision to ship its RHEL 6 kernel source as one big tarball. "Recently, Jonathan Corbet, respected kernel community member and editor at LWN, commented on our change in kernel RPM packaging. When we released RHEL 6 approximately four months ago, we changed the release of the kernel package to have all our patches pre-applied. Why did we make this change? To speak bluntly, the competitive landscape has changed. Our competitors in the Enterprise Linux market have changed their commercial approach from building and competing on their own customized Linux distributions, to one where they directly approach our customers offering to support RHEL. Frankly, our response is to compete."

Comments (149 posted)

Web Video Rivalry Sparks U.S. Probe (WSJ)

The Wall Street Journal has posted an article stating that the MPEG LA is under investigation in the US for its attempt to build a patent pool to attack the VP8 codec. "The probe, which pits Google and open-source software advocates against some technology giants like Apple, could help determine whether anyone will own rights over the creation and broadcast of online video in the next major Web programming language, called HTML 5. At stake is 'who is going to have competitive clout in the world after television,' said Eben Moglin [sic], a Columbia University professor who supports free and open software."

Comments (34 posted)

FSFE Newsletter - March 2011

The Free Software Foundation Europe newsletter for March covers Egypt's attempt to shut down the internet, FSFE's legal workshop, and several other topics.

Full Story (comments: none)

The Linux Foundation Announces Keynotes for Annual Collaboration Summit

The Linux Foundation has announced the keynotes and the full program for this year's Collaboration Summit. The Summit takes place April 6-8, 2011 in San Francisco, California. "The Linux Foundation Collaboration Summit is the only event where a cross-section of leaders from the Linux developer, industry and end user communities meet face-to-face to tackle today's most pressing issues facing Linux, including technical development, legal topics, ISV porting and end user requirements. The Summit is an invitation-only event that caters to Linux Foundation members and workgroup contributors. It is designed to accelerate collaboration and problem solving by bringing key stakeholders together in a neutral setting."

Comments (none posted)

LUGOD presents "Full Scale Flight Simulators"

The Linux Users' Group of Davis (LUGOD) will be holding a meeting on March 21, 2011 with a presentation by John Wojnaroski, Chief Engineer, LFS Technologies, Inc. on "Full Scale Flight Simulators". "LFS Technologies has developed a suite of hardware, electronics, and software that has been integrated with open source projects such as FlightGear flight simulator, JSBSim flight dynamics model, and OpenSceneGraph. The preferred platform is a Linux-based PC with the real-time extensions provided by RTAI/Xenomai."

Full Story (comments: none)

PgEast 2011: Session Schedule Up, registration open

PgEast, the PostgreSQL Conference for Developers, End Users and Decision Makers, will take place March 22-25, 2011, in New York City. "This year we will be continuing our trend of covering the entire PostgreSQL ecosystem as well as bringing in some friends from a slightly different world, NoSQL. 10gen, the creators of MongoDB are running a track through the entire three days and also hosting a full day training on their database!"

Full Story (comments: none)

PyWeek 12 is registration is open

Registration is open for the 12th Python Game Programming Challenge (PyWeek), which takes place April 3-10, 2011.

Full Story (comments: none)

Events: March 17, 2011 to May 16, 2011

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
March 19	Open Source Conference Oita 2011	Oita, Japan
March 19 March 20	Chemnitzer Linux-Tage	Chemnitz, Germany
March 19	OpenStreetMap Foundation Japan Mappers Symposium	Tokyo, Japan
March 21 March 22	Embedded Technology Conference 2011	San Jose, Costa Rica
March 22 March 24	OMG Workshop on Real-time, Embedded and Enterprise-Scale Time-Critical Systems	Washington, DC, USA
March 22 March 25	Frühjahrsfachgespräch	Weimar, Germany
March 22 March 24	UKUUG Spring 2011 Conference	Leeds, UK
March 22 March 25	PgEast PostgreSQL Conference	New York City, NY, USA
March 23 March 25	Palmetto Open Source Software Conference	Columbia, SC, USA
March 26	10. Augsburger Linux-Infotag 2011	Augsburg, Germany
March 28 April 1	GNOME 3.0 Bangalore Hackfest | GNOME.ASIA SUMMIT 2011	Bangalore, India
March 28	Perth Linux User Group Quiz Night	Perth, Australia
March 29 March 30	NASA Open Source Summit	Mountain View, CA, USA
April 1 April 3	Flourish Conference 2011!	Chicago, IL, USA
April 2 April 3	Workshop on GCC Research Opportunities	Chamonix, France
April 2	Texas Linux Fest 2011	Austin, Texas, USA
April 4 April 5	Camp KDE 2011	San Francisco, CA, USA
April 4 April 6	SugarCon ’11	San Francisco, CA, USA
April 4 April 6	Selenium Conference	San Francisco, CA, USA
April 6 April 8	5th Annual Linux Foundation Collaboration Summit	San Francisco, CA, USA
April 8 April 9	Hack'n Rio	Rio de Janeiro, Brazil
April 9	Linuxwochen Österreich - Graz	Graz, Austria
April 9	Festival Latinoamericano de Instalación de Software Libre
April 11 April 14	O'Reilly MySQL Conference & Expo	Santa Clara, CA, USA
April 11 April 13	2011 Embedded Linux Conference	San Francisco, CA, USA
April 13 April 14	2011 Android Builders Summit	San Francisco, CA, USA
April 16	Open Source Conference Kansai/Kobe 2011	Kobe, Japan
April 25 April 26	WebKit Contributors Meeting	Cupertino, USA
April 26 April 29	OpenStack Conference and Design Summit	Santa Clara, CA, USA
April 28 April 29	Puppet Camp EU 2011: Amsterdam	Amsterdam, Netherlands
April 29	Ottawa IPv6 Summit 2011	Ottawa, Canada
April 29 April 30	Professional IT Community Conference 2011	New Brunswick, NJ, USA
April 30 May 1	LinuxFest Northwest	Bellingham, Washington, USA
May 3 May 6	Red Hat Summit and JBoss World 2011	Boston, MA, USA
May 4 May 5	ASoC and Embedded ALSA Conference	Edinburgh, United Kingdom
May 5 May 7	Linuxwochen Österreich - Wien	Wien, Austria
May 6 May 8	Linux Audio Conference 2011	Maynooth, Ireland
May 9 May 11	SambaXP	Göttingen, Germany
May 9 May 10	OpenCms Days 2011 Conference and Expo	Cologne, Germany
May 9 May 13	Linaro Development Summit	Budapest, Hungary
May 9 May 13	Ubuntu Developer Summit	Budapest, Hungary
May 10 May 13	Libre Graphics Meeting	Montreal, Canada
May 10 May 12	Solutions Linux Open Source 2011	Paris, France
May 11 May 14	LinuxTag - International conference on Free Software and Open Source	Berlin, Germany
May 12	NLUUG Spring Conference 2011	ReeHorst, Ede, Netherlands
May 12 May 15	Pingwinaria 2011 - Polish Linux User Group Conference	Spala, Poland
May 12 May 14	Linuxwochen Österreich - Linz	Linz, Austria

If your event does not appear here, please tell us about it.

SCALE Report: SCALE 9X ends on a high note

The SCALE team reports that last month's Southern California Linux Expo had record attendance. ""Because SCALE is the first large Linux and FOSS show in 2011, it serves as an indicator of how the year may go," said Orv Beach, the SCALE 9X publicity co-chair. "From what we've seen this weekend at SCALE, the upcoming months look very bright for FOSS.""

Full Story (comments: 1)

Video of Mark Pesce's LCA keynote available

The video from Mark Pesce's controversial linux.conf.au keynote has now been posted. The LCA organizers have put a warning and apology at the beginning, but have not otherwise edited the talk.

Comments (14 posted)