LWN.net Weekly Edition for April 1, 2010

The demise of PlayStation Linux

Sony uses embedded Linux in a wide variety of its consumer electronics products: televisions, video recorders, navigation devices, and more. Up until fairly recently, it gave something back to the community by supporting Linux installation on its PlayStation game consoles. While Sony removed the "Install Other OS" option on new PlayStation 3 (PS3) systems back in August 2009, there were millions of older PS3s that could be used for Cell processor hacking on Linux—no more.

Sony announced [Japanese press release] (LWN coverage) that the v3.21 firmware release will disable the "Install Other OS" feature, but it also threatens users with a long list of features that will no longer work if the "upgrade" isn't installed. One might guess that either April fools day is not celebrated in Japan or that Sony Computer Entertainment (SCE) is irony-impaired because the release date for the firmware is April 1. The timing is also a bit suspicious in that it seems like a measure aimed at punishing the "mod" community for a recent successful PS3 "jailbreak".

The ostensible reason for removing the "Install Other OS" feature is "security concerns", but as PS3 hacker George Hotz points out, jailbreaking the PS3 requires opening up the enclosure. The procedure is not for the faint-of-heart—it involves pulsing a particular solder point on the PS3 board "low for ~40ns". This is not something a casual user will have any way to do, if they were even willing to try it. It certainly isn't a vector for malware attacks either.

Unsuspecting PS3 Linux users who upgrade will lose the contents of the Linux portion of the hard drive. Because of that, and other restrictions enforced in the new firmware, Hotz has vowed to find a way around those restrictions. He previously had no plans to create custom firmware for the device, but because of SCE's latest move, he does now:

Hotz has also been part of the iPhone/iPod/iPad jailbreaking community, having released multiple software and hardware jailbreaking hacks for those platforms, so his track record is good. That means it is pretty likely he will come up with a way to run v3.21 and still run Linux—just what SCE evidently fears. But he is also clear that doing so is not about "piracy", it is about taking back the control of your device: "Hacking isn't about getting what you didn't pay for, it's about making sure you do get what you did."

That is the crux of the matter for many. Without the firmware update, PS3 owners will not be able to do a number of things they thought they got when buying the device: playing games online, watching new Blu-ray videos, playing new PS3 games, and so on. The EFF is concerned that new Blu-ray disks could even completely disable the Blu-ray drive by revoking the AACS decryption key in the older firmware. Because of the digital rights management (DRM) features included in content meant to be used by PS3s, SCE has the technical means to stop existing, working devices from performing those tasks on new content. The EFF puts it this way:

SCE would undoubtedly argue that it needs to maintain the integrity of its online games, so requiring certain firmware upgrades to participate in its network is reasonable. There is something to that argument, but there is zero evidence that allowing Linux (or any other OS) to be installed had played any kind of role in game "cheats"—in fact its hard to see how it could. If anything is flawed, it is the hardware which allowed Hotz to essentially circumvent the hypervisor that SCE put in place to wall off Linux from the 3D video hardware. In addition, that argument falls flat when considering playing new DVDs or local games.

It is believed that PS3s which need to be serviced for a hardware problem of some kind will be silently upgraded to the latest firmware, which would wipe out any Linux partition on the disk. So, who owns this device that you have, supposedly, bought and paid for? Once a given set of features is released, and works, isn't the manufacturer honor-bound (if not legally bound) to not actively work to disable those features? Some PS3 customers relied on being able to install Linux, while still keeping the other features of the console. In fact, SCE made assurances that the "Install Other OS" feature would be maintained as recently as February.

It is interesting to note that there are folks in the HPC community who were buying PS3s by the thousands to create Linux clusters. Other than the occasional fragging expedition at lunch, one would guess that the vast majority of those machines never actually run games at all. There is clearly a market for low-cost Cell-based machines, but SCE evidently doesn't see that—or can't make money at it. It may be running PS3s on the razor blade model; selling the consoles at a loss, while making up the difference by selling peripherals and games.

Its hard to see how SCE comes out of this looking like anything other than a bully. It sold hardware with a feature set that folks found attractive, so they bought them. Now, when it is somehow inconvenient for SCE to continue supporting some of those features, it turns them off, with little warning and almost no recourse. The vast majority of PS3 owners may be completely unaffected, but those who relied upon SCE's word may think twice before buying from it again. In the meantime, they are likely to follow Hotz's progress with great interest.

Comments (27 posted)

Open-source biotechnology

The free software community, along with the commercial ecosystem which surrounds it, is widely seen as having pointed the way toward successful, collaborative development of common resources. We have seen a number of attempts to port the free software model to other areas of endeavor. Open content, headlined by sites like Wikipedia, has adopted this model with considerable success. Other areas, such as open hardware, are still trying to find their way. Your editor recently read an interesting book (Rob Carlson's Biology is Technology), which raises an interesting question: is there a place for an ecosystem based around free "software" running on biological processors?

The core point of the book is that biological hacking is quickly headed toward becoming yet another engineering discipline. The "device physics" of standard parts are being worked out, the development tools are becoming more sophisticated, and the level of skill required to do interesting things is dropping. The annual International Genetically Engineered Machine competition which is intended, among other things, to increase the number of "biological parts" available, is getting high-scoring entries from high school students. The amount of hacking on biological substrates is increasing quickly, and will continue to do so.

The amount of creativity we will be seeing in this area inspires both hope and outright terror. Biological hacking has the potential to transform health care, address energy problems, mitigate climate change, and more. Or it could wreak environmental devastation and facilitate horrifying attacks by either individuals or governments. Carlson strongly advocates openness as the best policy for dealing with this technology. Only through openness, he says, will we develop the kind of economy we need to make the best use of this new technology while simultaneously understanding what others are up to and defending ourselves against mistakes and abuses. Trying to keep technology under wraps never works. Your editor might compare attempts to restrict biotechnology with governmental efforts to restrict encryption technology a generation ago.

Openness does not just mean freedom from regulatory interference, though; Carlson takes a long look at the possibility of creating a successful commercial ecosystem based on the open source model. At an abstract level, the idea looks compelling: it is not hard to see programming with nucleotides as being fundamentally the same task as programming with bits. A nucleotide is able to encode two bits rather than one, and the underlying processor is smaller, wetter, and smellier, but it's a program nonetheless. Given that tools for working with DNA are following a path similar to that of computers - they are rapidly becoming smaller, cheaper, and more powerful - there is a lot to be said for the creation of freely-licensed libraries based on genetic programs developed in garages and basements.

There are some efforts afoot to do exactly that. The BioBricks Foundation is working toward the creation of a set of freely-available biological components. Another initiative is Biological Open Source, appropriately known as BiOS. These efforts are promising, but there is a large problem looming - one which will be familiar to LWN readers.

That problem, of course, is patents. Genetic sequences are currently patentable in the US and elsewhere, so companies operating in this area are accumulating as many of them as possible. Things are quickly getting to the point where it is difficult to work commercially in biotechnology without running into patents held by others - patents which, often, cover fundamental natural phenomena. Carlson brings up some interesting history; it seems that the automotive and aviation industries both ran into this problem; in both cases, it got to where companies could not do anything because they were forever caught up in patent litigation. In both cases, in the US, the government intervened, forcing the creation of patent pools so that companies would stop suing each other and get back to doing interesting things with the technology.

Patent pools (like patents in general) favor large, established corporations over smaller companies. But it's the small companies which are the source of most innovation in any field. Carlson worries that the US is headed toward a situation where those companies cannot afford to exist and innovation will be strangled. An open-source-like approach to biotechnology might just be a way out of that situation.

But doing open source in this field, despite its similarities with software, is going to be hard. Software gets copyright protection worldwide; that makes it easy to use copyright licensing to create a legal regime where people (and companies) feel that it is in their interest to contribute. Genetic sequences have no such protection, so patents are the only way to go for anybody feeling the need to gain a degree of control over how a discovery is used. Copyleft-style patent licensing is possible, but it is more awkward, and, in any case, the high cost of obtaining patents creates a barrier to entry that does not exist for licensing based on copyrights. Lone biohackers working in their garages are not going to be contributing components to a community based on patents.

As a result of the different legal environment, open-source-like efforts in biotechnology must form their understandings under different terms than the software community uses. BioBricks must be placed in the public domain; the draft BioBrick Public Agreement - a contributor agreement, not a license - requires contributors to give "An irrevocable promise not to assert any property rights held by the Contributor over Users of the contributed Materials." BiOS, instead, is organized more like a patent pool with a fee to enter. Neither of these approaches is seen (by Carlson) as being ideal, but he also admits to being short of better ideas.

What may be required, in the end, is a new and different legal regime for biological discoveries. As Carlson notes, neither patents nor copyrights are mentioned by name in the US Constitution; they are legislative creations. Someday, maybe, a legislature rather more enlightened than those governing us now will find a way to foster open biotechnology development that works at all levels. It will be interesting to see whether the recent US District Court ruling throwing out genetic patents inspires any useful thinking in that direction.

One need not be a speculative fiction author to imagine a future world where the freedom to use, modify, and distribute biological code is (at least) as important as those freedoms applied to software running on silicon. We do not seem to be building a world which includes those freedoms, though; we do not even really have a good sense for what that world would look like. The biotechnology industry, it seems, is in need of its own personalities to fill the roles Richard Stallman, Linus Torvalds, and the many others who have helped to make free software work.

Comments (25 posted)

SCO loses again

It has been just over seven years since the "SCOSource" initiative showed its true colors and filed suit against IBM asking for $1 billion in damages. Much has happened in that time; the nature of the charges has evolved considerably, the price tag has increased, other companies have been pulled in, and SCO has gone into bankruptcy. In the process, SCO attack has, like a vaccination, served to strengthen the community's legal defenses considerably. It has been a wild show to watch.

One of the most surprising developments came when Novell abruptly announced that, in fact, it (and not SCO) was the owner of the Unix copyrights upon which much of the litigation was based. SCO responded with a "slander of title" lawsuit which has been a convoluted multi-year affair in its own right. But, on March 30, a jury in US District Court ruled that, in fact, no copyrights had been transferred to SCO and that Novell remained the owner of Unix.

This outcome was far from guaranteed. SCO's claims against IBM and the Linux community have been repeatedly shown to be without merit, but the Novell litigation was different. That was all based on a vague "asset purchase agreement," twice amended, which was seemingly written by lawyers who were not doing their job. What SCO purchased was truly unclear, and there was no telling what a jury might decide. Now, perhaps, we have some clarity.

It is tempting to see this ruling as the end of the story; rightfully it should be. But anybody who has watched this case for any period of time knows better. The SCO affair is kind of like a bad zombie movie; the plot is implausible, the acting is horrible (ask any of us who sat though all those "Chris and Darl show" conference calls back at the beginning), and, even though you know the good guys must win in the end, that obnoxious zombie just keeps coming back and ruining the party. SCO, which has just obtained a $2 million loan from Ralph Yarro (one of the original architects of this whole mess), may well appeal. Or perhaps it will find a willing buyer for the lawsuit out there. It does not seem like SCO to slip quietly into Chapter 7 bankruptcy at this point.

One should also remember that the Novell case was a sideshow; IBM is the main event. Losing the ownership of the copyrights clearly cannot help SCO's case, but it has long since been shown that there's nothing covered by those copyrights in Linux anyway. Much of the dispute was over code clearly owned by IBM, but which SCO claimed could only be distributed under the proprietary Unix terms. SCO might just choose to pursue its breach of contract (and related) claims. The fact that Novell claims the right to issue "get out of jail free" cards with regard to Unix licensing will complicate matters, and could prove fodder for extensive legal maneuvering in its own right.

Meanwhile, as long as some shred of SCO remains, one can only imagine that IBM will not be in a mood to forgive, forget, or drop its counterclaims. IBM has clearly put many millions of dollars into this fight; its chances of getting any of that back would appear to be approximately zero, but IBM is unlikely to want to leave SCO in a position to plan another attack.

SCO has long since ceased to be a threat to Linux, of course; at this point, most of us can afford to sit back and watch the remainder of the show. But we should not forget that SCO set out to kill our community. The attack was baseless and clownish, but it still created considerable uncertainty and expense. The sad fact of the matter is that, when companies lose in the market, they try to win in the courtroom, especially in the US. There will be other attackers, and at least some of those attackers will not make so many silly mistakes.

In the past, LWN has asked Novell to clarify what it intends to do with the Unix copyrights that, once again, it seems to clearly own. Those copyrights cannot have much - if any - commercial value at this point. It would make great sense for Novell to release all of that code as free software, optimally under a permissive license. Until that happens, those copyrights will be a temptation to those who think they can somehow use them in litigation. That zombie, at least, can be definitively killed.

Comments (9 posted)

Page editor: Jonathan Corbet

Security

Web application scanning with skipfish

Web application security flaws are, as always, a hot area in security research, and it isn't surprising that a company which derives much of its income from the web would be interested in helping to secure it. Google has released several tools over the past couple of years—along with a Browser Security Handbook—many of which have been written by longtime security researcher Michal Zalewski. His latest release, skipfish, is an automated web application scanner that actively probes to find vulnerabilities.

Skipfish is a high-performance tool that can do several hundred to several thousand requests per second. Each of those requests tests a different kind of potential security flaw in an application. It spiders a web application and tries its tests on each of the pages it finds. For any complicated application, that will result in huge numbers of requests—and probably errors—but because of the post-processing it does to its results, it summarizes the reported problems in a fairly manageable way.

The code itself is 12,000 lines of C, which builds from a simple make as long as libidn is available to handle internationalized domain names. The program is command-line driven with top-like, continuously updating output (seen at right). Zalewski made some odd choices for colors in that output, making it hard to find a terminal color-scheme where it was readable. The recommended 100x35 terminal size is decidedly non-standard as well. Those nits aside, it is quite easy to get started with skipfish.

Understanding what one should do with skipfish is another story entirely. There is a large number of tests that are run, which are listed on the documentation page. That page also provides some examples of using the tool. As one might guess, there are a large number of options to handle different application needs like cookie values, HTTP authentication credentials, logout URLs to avoid, and so on. Before getting to that point, though, one must choose a dictionary.

Dictionaries in skipfish provide a starting point for the scanner to find additional URLs, files, and parameters that are used by the web application. There are four different dictionaries distributed with skipfish (minimal, default, extensions-only, and complete), and the tool will add what it learns to the dictionary as it runs. The dictionaries/README-FIRST file describes each dictionary as well as how the dictionaries are used. The minimal.wl dictionary is suggested as a good, lightweight starting point for skipfish experimentation.

And one gets the sense that a lot of experimentation will be required before any kind of skipfish-mastery is achieved. That said, a fairly short run of skipfish against a local development version of a reasonably complex web application turned up several obvious, though relatively minor, problems. There is also quite a bit more to go through in the report, so there are likely more problems awaiting discovery in even a small sample of skipfish's capabilities. One note of warning for those that have their application email with significant errors: either disable that, or you may get a chance to stress your mail server and/or be subjected to an inbox denial-of-service.

The report that skipfish produces is a summary of the problems, or potential problems that it found. It is in HTML format, that, somewhat amusingly, requires Javascript to be turned on to be useful. In fact, the "known issues" page mentions that due to "important security improvements" in Safari and Chrome, neither of those browsers will display the report via the file: protocol—"put the report in a local WWW root and navigate to http://localhost/... instead; or use Firefox".

In the report, various categories of problems found are listed with color-coded icons to estimate the severity of the problem. Categories can be clicked on which will expose a list of the pages that exhibited the problem. For each of those, an HTTP trace can be examined (example shown at left). While some of the categories are fairly obvious, some are a bit more obscure and will require some investigation to determine whether there is truly a problem or not.

Like most, if not all, automated scanners, there will be plenty of false-positives reported, which means that the results will have to be sifted to find the real problems. Skipfish is aimed at minimizing false-positives, but it will still require an iterative approach. Limiting the search to the "interesting" parts of the application, without missing something important in the portions deemed "unimportant" will be somewhat tricky to get right.

Most web applications have vast numbers of pages that are governed by the same underlying code, so picking a truly representative sample of one of those pages is important. Otherwise, skipfish will spend an awful lot of time repetitively testing the same kinds of things against "/ExampleContent/1", "/ExampleContent/2", and so on. The same problem exists for any automated web scanner, of course.

As the documentation points out, there are other tools that do similar jobs (Nikto and Nessus are given as examples), and skipfish is "not a silver bullet". But, clearly a lot of thought has gone into it, and Zalewski has an excellent track record as a finder of security vulnerabilities. Skipfish is certainly a tool that is worth a long look.

Comments (none posted)

Brief items

Mozilla: Plugging the CSS History Leak

The Mozilla security blog discusses their response to the leaking of browser history information via CSS link styling. "First of all, we're limiting what types of styling can be done to visited links to differentiate them from unvisited links. Visited links can only be different in color: foreground, background, outline, border, SVG stroke and fill colors. All other style changes either leak the visitedness of the link by loading a resource or changing position or size of the styled content in the document, which can be detected and used to identify visited links."

Comments (1 posted)

New vulnerabilities

brltty: privilege escalation

Package(s):	brltty	CVE #(s):	CVE-2008-3279
Created:	March 31, 2010	Updated:	April 19, 2010
Description:	The brltty daemon has an insecure library search path built into the the executable, allowing a local attacker who applies sufficient social engineering to run code as another local user.
Alerts:	Mandriva MDVSA-2010:080 2010-04-17 Red Hat RHSA-2010:0181-05 2010-03-30

Comments (none posted)

emacs: symlink race

Package(s):	emacs22, emacs23	CVE #(s):	CVE-2010-0825
Created:	March 30, 2010	Updated:	August 30, 2010
Description:	From the Ubuntu advisory: Dan Rosenberg discovered that the email helper in Emacs did not correctly check file permissions. A local attacker could perform a symlink race to read or append to another user's mailbox if it was stored under a group-writable group-"mail" directory.
Alerts:	MeeGo MeeGo-SA-10:11 2010-08-03 Mandriva MDVSA-2010:083 2010-04-20 Ubuntu USN-919-1 2010-03-29

Comments (none posted)

fcron: symlink attack

Package(s):	fcron	CVE #(s):	CVE-2010-0792
Created:	March 29, 2010	Updated:	March 31, 2010
Description:	From the CVE entry: fcrontab in fcron before 3.0.5 allows local users to read arbitrary files via a symlink attack on an unspecified file.
Alerts:	Fedora FEDORA-2010-4063 2010-03-10

Comments (none posted)

gnutls: arbitrary code execution

Package(s):	gnutls	CVE #(s):	CVE-2010-0731
Created:	March 25, 2010	Updated:	August 2, 2010
Description:	From the Red Hat advisory: A flaw was found in the way GnuTLS extracted serial numbers from X.509 certificates. On 64-bit big endian platforms, this flaw could cause the certificate revocation list (CRL) check to be bypassed; cause various GnuTLS utilities to crash; or, possibly, execute arbitrary code. (CVE-2010-0731)
Alerts:	SUSE SUSE-SR:2010:014 2010-08-02 Mandriva MDVSA-2010:089 2010-05-03 CentOS CESA-2010:0167 2010-03-28 Red Hat RHSA-2010:0167-01 2010-03-25

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2010-0727
Created:	March 25, 2010	Updated:	September 1, 2010
Description:	From the Mandriva advisory: The gfs2_lock function in the Linux kernel before 2.6.34-rc1-next-20100312, and the gfs_lock function in the Linux kernel on Red Hat Enterprise Linux (RHEL) 5 and 6, does not properly remove POSIX locks on files that are setgid without group-execute permission, which allows local users to cause a denial of service (BUG and system crash) by locking a file on a (1) GFS or (2) GFS2 filesystem, and then changing this file's permissions. (CVE-2010-0727)
Alerts:	SUSE SUSE-SA:2010:036 2010-09-01 Ubuntu USN-947-2 2010-06-04 Debian DSA-2053-1 2010-05-25 Red Hat RHSA-2010:0380-01 2010-04-27 Red Hat RHSA-2010:0331-01 2010-03-30 Red Hat RHSA-2010:0521-01 2010-07-08 Red Hat RHSA-2010:0330-01 2010-03-30 Red Hat RHSA-2010:0291-04 2010-03-30 Red Hat RHSA-2010:0178-02 2010-03-30 Mandriva MDVSA-2010:066 2010-03-24 Ubuntu USN-947-1 2010-06-03

Comments (2 posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2010-1083 CVE-2010-1086 CVE-2010-1088
Created:	March 30, 2010	Updated:	October 8, 2010
Description:	From the SUSE advisory: CVE-2010-1083: A kernel information leak using user space USB devices could be used by local attackers with USB access to read recently freed kernel memory. CVE-2010-1086: A ULE decapsulation denial of service problem in DVB drivers was fixed that could be triggered by invalid DVB data packets. CVE-2010-1088: A NFS denial of service by following "automount" symlinks was fixed.
Alerts:	Mandriva MDVSA-2010:188 2010-09-23 SUSE SUSE-SA:2010:036 2010-09-01 Mandriva MDVSA-2010:198 2010-10-07 Red Hat RHSA-2010:0631-01 2010-08-17 Red Hat RHSA-2010:0723-01 2010-09-29 CentOS CESA-2010:0723 2010-09-30 Ubuntu USN-947-1 2010-06-03 CentOS CESA-2010:0398 2010-05-28 Pardus 2010-64 2010-06-04 Ubuntu USN-947-2 2010-06-04 Debian DSA-2053-1 2010-05-25 Pardus 2010-63 2010-05-18 CentOS CESA-2010:0394 2010-05-08 Red Hat RHSA-2010:0398-01 2010-05-06 SuSE SUSE-SA:2010:023 2010-05-06 Red Hat RHSA-2010:0394-01 2010-05-05 Mandriva MDVSA-2010:088 2010-04-30 Pardus 2010-57 2010-04-27 CentOS CESA-2010:0504 2010-07-02 SuSE SUSE-SA:2010:019 2010-03-30 Red Hat RHSA-2010:0504-01 2010-07-01

Comments (none posted)

kvm: denial of service

Package(s):	kvm	CVE #(s):	CVE-2010-0741
Created:	March 31, 2010	Updated:	June 4, 2010
Description:	A flaw in how QEMU-KVM handles erroneous data allows a remote attacker to crash a guest system by sending specially-crafted data.
Alerts:	Ubuntu USN-947-1 2010-06-03 Pardus 2010-51 2010-04-20 Red Hat RHSA-2010:0271-04 2010-03-30 Ubuntu USN-947-2 2010-06-04

Comments (none posted)

moin: cross-site scripting

Package(s):	moin	CVE #(s):	CVE-2010-0828
Created:	March 31, 2010	Updated:	June 14, 2010
Description:	The moin wiki system suffers from a cross-site scripting vulnerability in its "Despam" action.
Alerts:	Fedora FEDORA-2010-6012 2010-04-09 Fedora FEDORA-2010-6134 2010-04-09 Ubuntu USN-925-1 2010-04-08 Debian DSA-2024-1 2010-03-31 Gentoo 201210-02 2012-10-18

Comments (none posted)

moodle: cross-site scripting

Package(s):	moodle	CVE #(s):
Created:	March 29, 2010	Updated:	March 31, 2010
Description:	From the Red Hat bugzilla: An XSS flaw was reported in the phpCAS library, where it would not properly sanitize the submitted URL before displaying it on the error page. This could allow an attacker to insert scripts or other malicious content on the error page.
Alerts:	Fedora FEDORA-2010-5356 2010-03-26 Fedora FEDORA-2010-5370 2010-03-26

Comments (none posted)

Mozilla products: multiple vulnerabilities

Package(s):	firefox seamonkey thunderbird	CVE #(s):	CVE-2010-0174 CVE-2010-0175 CVE-2010-0176 CVE-2010-0177 CVE-2010-0178 CVE-2010-0179
Created:	March 31, 2010	Updated:	January 27, 2011
Description:	The Firefox 3.0.19 and 3.5.9 (3.0.19 being the final planned 3.0.x update), Thunderbird 3.0.4, and SeaMonkey 2.0.4 updates fix a number of vulnerabilities.
Alerts:	CentOS CESA-2010:0966 2011-01-27 SUSE SUSE-SA:2011:003 2011-01-05 Mandriva MDVSA-2010:251-2 2010-12-24 openSUSE openSUSE-SU-2010:1054-2 2010-12-21 openSUSE openSUSE-SU-2010:1054-1 2010-12-13 Fedora FEDORA-2010-18775 2010-12-09 Fedora FEDORA-2010-18773 2010-12-09 Fedora FEDORA-2010-18775 2010-12-09 Fedora FEDORA-2010-18773 2010-12-09 Fedora FEDORA-2010-18775 2010-12-09 Fedora FEDORA-2010-18773 2010-12-09 Fedora FEDORA-2010-18775 2010-12-09 Fedora FEDORA-2010-18773 2010-12-09 Fedora FEDORA-2010-18775 2010-12-09 Fedora FEDORA-2010-18773 2010-12-09 Fedora FEDORA-2010-18775 2010-12-09 Fedora FEDORA-2010-18773 2010-12-09 Fedora FEDORA-2010-18775 2010-12-09 Fedora FEDORA-2010-18773 2010-12-09 CentOS CESA-2010:0544 2010-08-06 Pardus 2010-62 2010-05-18 Mandriva MDVSA-2010:070-1 2010-04-20 Red Hat RHSA-2010:0545-01 2010-07-20 SuSE SUSE-SR:2010:013 2010-06-14 Mandriva MDVSA-2010:070 2010-04-13 SuSE SUSE-SA:2010:021 2010-04-14 Ubuntu USN-920-1 2010-04-09 Ubuntu USN-921-1 2010-04-09 Fedora FEDORA-2010-5515 2010-04-01 CentOS CESA-2010:0332 2010-04-06 CentOS CESA-2010:0333 2010-04-06 CentOS CESA-2010:0333 2010-04-06 Pardus 2010-47 2010-04-06 Slackware SSA:2010-095-03 2010-04-05 Slackware SSA:2010-095-02 2010-04-05 Slackware SSA:2010-095-01 2010-04-05 Fedora FEDORA-2010-5840 2010-04-03 Debian DSA-2027-1 2010-04-03 Slackware SSA:2010-090-03 2010-04-01 Slackware SSA:2010-090-02 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5506 2010-04-01 Fedora FEDORA-2010-5506 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5506 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5506 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5506 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5506 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5506 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5506 2010-04-01 Fedora FEDORA-2010-5515 2010-04-01 Fedora FEDORA-2010-5539 2010-04-01 Fedora FEDORA-2010-5526 2010-04-01 Fedora FEDORA-2010-5539 2010-04-01 Fedora FEDORA-2010-5526 2010-04-01 Slackware SSA:2010-202-02 2010-07-22 Slackware SSA:2010-202-01 2010-07-22 CentOS CESA-2010:0545 2010-07-22 Red Hat RHSA-2010:0333-01 2010-03-30 Red Hat RHSA-2010:0332-01 2010-03-30 Red Hat RHSA-2010:0544-01 2010-07-20 Gentoo 201301-01 2013-01-07

Comments (none posted)

openssl: multiple vulnerabilities

Package(s):	openssl	CVE #(s):	CVE-2009-3245 CVE-2010-0433
Created:	March 25, 2010	Updated:	April 12, 2011
Description:	From the Red Hat advisory: It was discovered that OpenSSL did not always check the return value of the bn_wexpand() function. An attacker able to trigger a memory allocation failure in that function could cause an application using the OpenSSL library to crash or, possibly, execute arbitrary code. (CVE-2009-3245) A missing return value check flaw was discovered in OpenSSL, that could possibly cause OpenSSL to call a Kerberos library function with invalid arguments, resulting in a NULL pointer dereference crash in the MIT Kerberos library. In certain configurations, a remote attacker could use this flaw to crash a TLS/SSL server using OpenSSL by requesting Kerberos cipher suites during the TLS handshake. (CVE-2010-0433)
Alerts:	Gentoo 201110-01 2011-10-09 rPath rPSA-2011-0013-1 2011-04-11 CentOS CESA-2010:0977 2011-01-27 Red Hat RHSA-2010:0977-01 2010-12-13 Ubuntu USN-1003-1 2010-10-07 rPath rPSA-2010-0036-1 2010-05-07 SuSE SUSE-SR:2010:013 2010-06-14 Mandriva MDVSA-2010:076-1 2010-04-19 Mandriva MDVSA-2010:076 2010-04-15 Fedora FEDORA-2010-5357 2010-03-26 SuSE SUSE-SA:2010:020 2010-04-06 Slackware SSA:2010-090-01 2010-04-01 CentOS CESA-2010:0162 2010-03-27 CentOS CESA-2010:0173 2010-03-25 Red Hat RHSA-2010:0173-02 2010-03-25 Red Hat RHSA-2010:0162-01 2010-03-25

Comments (none posted)

sendmail: message spoofing

Package(s):	sendmail	CVE #(s):	CVE-2006-7176
Created:	March 31, 2010	Updated:	March 31, 2010
Description:	From the Red Hat advisory: the configuration of sendmail in Red Hat Enterprise Linux was found to not reject the "localhost.localdomain" domain name for email messages that come from external hosts. This could allow remote attackers to disguise spoofed messages.
Alerts:	Red Hat RHSA-2010:0237-05 2010-03-30

Comments (none posted)

trac: unauthorized ticket modification

Package(s):	trac	CVE #(s):
Created:	March 30, 2010	Updated:	March 31, 2010
Description:	From the Trac changelog: Trac 0.11.7 fixes a ticket validation issue that would allow unauthorized users to modify the status and resolution of a ticket.
Alerts:	Fedora FEDORA-2010-4287 2010-03-12 Fedora FEDORA-2010-4318 2010-03-12

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel is 2.6.34-rc3, released on March 30. "Anyway, from a messy -rc2 we now have a -rc3 that should be in much better shape. Regressions fixed, and the ShortLog is short enough to be worth posting to lkml." Testers who are using both SELinux and ext3 will want to read the announcement; a regression in previous kernels could leave such systems with corrupted security labels. The short-form changelog is in the announcement, or see the full changelog for all the details.

There have been no stable updates over the last week. There are no less than four updates in the review process, though: 2.6.27.46 (45 patches), 2.6.31.13 (89 patches), 2.6.32.11 (116 patches), and 2.6.33.2 (156 patches). The release of all of these updates can be expected on or after April 1.

Comments (none posted)

Quotes of the week

-- Linus Torvalds

-- Andrew Morton

-- Andy Lutomirski

Comments (none posted)

Toward a saner execve()

Contemporary Linux systems allow processes to set up their environments in any of a number of ways. For various reasons, developers sometimes want even more flexibility; in particular, they would like to take something away (filesystem access, network access, capabilities) from a running process, usually in the name of security. The problem is that such changes can actually make security worse; as has been seen many times, privileged programs can be made to do strange and unfortunate things when run in unexpected environments.

As Andy Lutomirski notes, one response to this problem is to disable setuid semantics as well. But there are a lot of ways for the execve() system call to change a process's privileges which do not involve setuid programs; this is especially true in the presence of security modules. So Andy has proposed a different idea: opt out of execve() instead. To that end, he proposes a new prctl() option (PR_RESTRICT_ME) which could be used to add restrictions to a running process; the first of those is that the process cannot call execve(). Disabling execve() would be mandatory before any other restrictions could be added.

But a process running in a restricted mode might still want to run other programs; that's how Linux programs often work. To accommodate that need, Andy has added a new system call, named execve_nosecurity(). This variant of execve() will run the indicated program, but it will perform absolutely no security transitions first. So no setuid, no SELinux type changes, etc. The end result is a system call with functionality similar to simply mapping the program into the caller's address space and running it directly. With execve_nosecurity(), it is not possible to increase privileges by running another program, so it should make the removal of capabilities from running processes safer.

This patch should address a number of the concerns developers have had with the restricting of privileges. It's hard to tell for sure, though, because there has been very little in the way of response so far.

Comments (6 posted)

The BKL end game

The removal of the big kernel lock (BKL) has been a kernel development goal for many years. The BKL creates scalability problems and provides some truly strange locking semantics that would be nice to eliminate. The actual work of removing this lock has been a long process, though; it is a tedious job requiring a fairly deep understanding of the affected code. Relatively few people are willing to do that work, so the BKL has survived for far longer than anybody might have liked.

One developer who has put some significant time into BKL removal is Arnd Bergmann; Arnd has just posted a patch series which promises to eliminate the BKL altogether - almost.

To that end, a number of significant changes have been made. The block and tty subsystems both get subsystem-level mutexes to replace their use of the BKL; that is a relatively tricky job because the locking semantics provided by a mutex are rather different. An extensive effort has been made to audit and document ioctl() and llseek() functions which still require the BKL; no other function called from the file_operations structure expects the BKL now. Code still requiring the BKL is now explicitly marked in the kernel configuration system, making it possible to build BKL-free kernels. The patch set also includes a significant series from Jan Blunck removing the BKL from much of the VFS layer.

What's left is a few "mostly obscure device driver modules." Arnd has used a fairly large value of "mostly obscure," though; the USB subsystem, for example, still has a BKL dependency. All told, there are 148 modules still using the BKL, most of which are drivers. That may seem like a lot, but it's a huge step in the right direction. Many of us may be running BKL-free kernels sooner than we might have expected.

Comments (2 posted)

Kernel development news

Disabling IRQF_DISABLED

Interrupt handlers run asynchronously in response to signals from the hardware. Since they pull the CPU away from whatever it was doing before, handlers are supposed to be very quick; they should, in most cases, tell the hardware to be quiet, arrange for any followup work to be done, and get out of the way. Historically, the situation has not been so simple, though, leading to a distinction between "fast" and "slow" handlers in the earliest days of Linux. It now seems, though, that this distinction could disappear as early as 2.6.35.

The core distinction between fast and slow handlers is this: fast handlers are run with further interrupts disabled, while slow handlers run with interrupts enabled. A slow handler, thus, can be interrupted by another handler, while a fast handler cannot. In an ideal world, slow handlers would not exist; they would all get their work done quickly and not monopolize the CPU, so there would be no point in interrupting them. In the real world, which includes problematic hardware, slow processors, and developers of varying ability, slow handlers have been a fact of life. The nature of some hardware (old IDE controllers, for example) makes it hard to avoid doing a lot of work in the interrupt handler. Meanwhile, other types of devices must have exceedingly fast interrupt response to avoid loss of data; a classic example here is a number of serial ports which are able to buffer exactly one character in the UART. The slow IDE work could not be allowed to delay serial processing; thus, the IDE interrupt handler had to be a slow one.

Over time, though, the situation has changed. Hardware has gotten smarter and better able to handle interrupt response latency. CPUs have gotten faster, so even a relatively slow handler can get a lot of work done quickly. The needs of the realtime tree (and other latency-sensitive workloads) have motivated the reworking of the worst interrupt-time offenders, and improvements in the kernel's deferred work mechanisms have made it easier to move work out of handlers. So the need for the distinction between the two types of interrupt handlers has been fading.

Simultaneously, problems associated with the fast/slow dichotomy have been growing. There is no way to run handlers for interrupts on shared lines (found on any system with a PCI bus) with interrupts disabled, because any other handler for a device on the same line can enable interrupts. Allowing interrupt handlers to interrupt each other leads to worse cache behavior and unpredictable completion times. What set off the recent discussion, though, was this patch from Andi Kleen which was aimed at addressing another problem: deeply nested interrupt handlers can overflow the processor's interrupt stack - a situation from which good things cannot be expected to ensue.

Andi's solution is to monitor the depth of the interrupt stack within the core kernel's interrupt-handling code. Should the stack become more than half full, the core code will no longer enable interrupts before calling slow handlers. In effect, it treats slow handlers as if they were fast handlers for the duration of the stack-space squeeze. This patch solved the problem that was being observed, but it ran into some trouble; in particular, Thomas Gleixner did not hesitate to make his dislike for the patch known. Your editor will try to rephrase the argument in slightly more polite terms; according to Thomas, the patch implemented a solution which was unreliable at best, was liable to create significant latencies in the system, and which ignored the real problem.

Said real problem, according to Thomas, is the fact that slow handlers exist at all. He would like to see a world where all interrupt handlers are run with interrupts disabled, and where all of those handlers get their work done quickly. Any extended interrupt processing should be moved to threaded handlers. In summary:

Linus initially squashed the idea, saying that a world where we only have fast handlers is not really possible:

It is interesting to note, though, that this position shifted over time. Linus (and others) expressed a number of concerns about running all handlers with interrupts disabled:

• The handlers for some devices simply have to do a lot of work, and that cannot be easily changed. Embedded systems, in particular, can have fussy hardware and slow processors.

• Some handlers will not work properly if interrupts are not enabled. In the past, some drivers have done things like waiting for a certain amount of time to pass (as reflected in changes to the jiffies variable). This dubious practice fails outright if interrupts are disabled: the timer interrupt will be blocked, and jiffies will not advance.

• Some hardware simply has strict latency requirements which cannot wait for another interrupt handler to finish its job.

Looking at all these worries, one might well wonder if a system which disabled interrupts for all handlers would function well at all. So it is interesting to note one thing: any system which has the lockdep locking checker enabled has been running all handlers that way for some years now. Many developers and testers run lockdep-enabled kernels, and they are available for some of the more adventurous distributions (Rawhide, for example) as well. So we have quite a bit of test coverage for this mode of operation already.

Another thing that happened over the last few years was the integration of the dynamic tick code, which disables the clock tick when the system is idle. Clock ticks are not turned back on for interrupt handlers. So any handler which expects jiffies to change while it is running will, sooner or later, go into a rather undignified infinite loop. Users tend to notice that kind of behavior, so most drivers which behave this way have long since been fixed.

Finally, the realtime tree developers have spent a great deal of time tracking down sources of latency; excessive time spent in interrupt handlers is one of the worst of those. So drivers which control hardware of interest have generally been fixed. The addition of threaded interrupt handlers has made it easier to fix drivers; most of the code can simply be pushed into the threaded handler with no other change at all.

Given all of this, Ingo Molnar felt confident in saying:

After hearing this from a few core developers, and after doing some research of his own, Linus eventually stopped opposing the idea and started talking about how it should be implemented. Thomas then posted a patch implementing the change. With this patch, the IRQF_DISABLED flag (used to indicate a fast handler) becomes a no-op; it is expected to be removed altogether in 2.6.36.

There are still some concerns about the change, especially with regard to slow hardware on embedded systems. In some of these cases, the problem can be solved with threaded interrupt handlers. Some developers worry, though, that threaded handlers impose too much latency on interrupt response. Improving on that situation is a task for the future; in the mean time, some interrupt handlers may just have to enable interrupts internally to get the required behavior. The preferred function for this purpose is local_irq_enable_in_hardirq(); its use can already be found in the IDE layer.

Since all of the technical obstacles have seemingly been overcome, chances are good that this patch will find its way into the kernel in the 2.6.35 merge window.

Comments (4 posted)

Evolutionary development of a semantic patch using Coccinelle

Creating patches is usually handwork; fixing one specific issue at a time. Once in a while though, there is janitorial work to be done or some infrastructure to change. Then, a larger number of issues have to be taken care of simultaneously, yet all of them are following the same basic pattern, e.g. a replacement. Such tasks are often addressed at the source-code level using scripts in sed, perl, and the like. This article examines the usage of Coccinelle, a tool targeted at exactly those kinds of repetitive patching jobs. Because Coccinelle understands C syntax, though, it can handle those jobs much more easily.

The major drawback of using scripts for code transformation is that they use non-trivial regular expressions in order to match previously unknown names, parse structures, and so forth. To simplify such tasks, "semantic patches"—patches that describe the kinds of changes to be made, rather than the specific line and difference that come in normal patches—have been introduced along with Coccinelle to process them. Coccinelle translates the source files to an abstract representation, making it easier to deal with C expressions, isomorphisms, code paths and so on. For an introduction, refer to Valerie Aurora's LWN article or the Coccinelle web site. This article will provide a step-by-step description how a semantic patch came into existence once a certain problem was identified.

Learning Coccinelle is still a bit challenging as information is scattered and, like with all languages, just listing the abilities is not even half of the story. Studying other semantic patches (in addition to asking on the mailing list) worked best for me, so in return this article describes the creation of a semantic patch from scratch. I would like to thank Julia Lawall for her immediate responses to my questions and bug reports.

The problem

An issue was pointed out while developing an I2C driver for hardware monitoring: the driver serving an I2C slave device (called client) uses i2c_set_clientdata() to store a pointer to its private data structure, usually somewhere in the probe function. In the remove function, the driver was then supposed to clear the pointer to the data structure before freeing it, because clients are not really removed but are just unbound from the driver. To prevent a dangling pointer in the still existing client, a typical fix looks like:

    +   i2c_set_clientdata(client, NULL);
        /* clientdata pointed to data before */
        kfree(data);

As this dangling pointer looks quite easy to miss, checking all drivers is a job perfectly suited for Coccinelle. The goal is a patch series fixing this flaw in I2C drivers all over the kernel tree. While the patch series Coccinelle successfully created will probably not be merged directly, it helped in finding a more generic solution. It was agreed that the i2c-core should clear the pointer to the private data structure as there is no guarantee for such pointers after the remove. A follow-up patch series will likely be based on the semantic patch presented below. In any case, the creation process will be useful for similar tasks in the future.

The task can be further divided into two sub-problems:

1. Find relevant kfree() calls, which have the private data structure as an argument
2. Check if clientdata is NULL already

If the latter is not the case, a fix is needed. For the following examples, Coccinelle 0.2.2 and a 2.6.34-rc1 kernel were used. Older kernels can also be used to get the idea, of course.

Find relevant kfree() calls

A typical remove() routine for an I2C driver looks like this (from drivers/rtc/rtc-pcf8563.c):

    static int pcf8563_remove(struct i2c_client *client)
    {
        struct pcf8563 *pcf8563 = i2c_get_clientdata(client);

        if (pcf8563->rtc)
            rtc_device_unregister(pcf8563->rtc);

        kfree(pcf8563);

        return 0;
    }

The pointer to the data structure of interest was obtained using i2c_get_clientdata(). When the structure itself gets freed, then a check for the call setting clientdata to NULL is needed. So this combination of i2c_get_clientdata() and kfree() is of interest, keeping in mind that the name of the pointer and its type can be anything. As Coccinelle parses the C source on an abstract level, this is easily possible using a few so-called metavariables in the header of our matching rule. Those can then carry the actual naming as used in the source file. Always remember that Coccinelle works on an abstract level. It is quite easy to forget as most of us are used to standard patches on source-code level. A first attempt of our semantic patch having one rule may look like this:

    @@
    // This is the rule header; metavariables must be declared here
    type T;
    identifier client, data;
    @@
        // The matching rule itself:
        // Catch the clientdata
        T data = i2c_get_clientdata(client);

        // then anything in between is allowed
        ...

        // prepend the fix if kfree() is found
    +	i2c_set_clientdata(client, NULL);
        kfree(data);

For the pcf8563 example above, this patch matches. That means, after the first line of the rule, the metavariable T will carry the type struct pcf8563 *, data will carry the identifier pcf8563 and client will carry the identifier client. Later use of these metavariables will, of course, be accordingly replaced. So, kfree(data) will in fact look for kfree(pcf8563). As this is also found, the match is complete and the line containing the fix will be added.

But the patch did not find all relevant places. The probe() function also has a dangling pointer in the error path. It wasn't matched as it uses i2c_set_clientdata() instead of i2c_get_clientdata(). So there should be an alternation in the semantic patch handling both cases. And to make it short, a third variant is necessary because other drivers use i2c_get_clientdata() without declaring the type on the same line. It is usually a good idea to do a little bit of grepping first to get an idea in what ways functions are called. Here is the patch including all alternations marked by "(", "|", and ")" in the first column:

    @@
    type T;
    identifier client, data;
    @@
    // Check if function uses clientdata
    (
        i2c_set_clientdata(client, data);
    |
        data = i2c_get_clientdata(client);
    |
        T data = i2c_get_clientdata(client);
    )
        // anything in between is allowed
        ...
    +	i2c_set_clientdata(client, NULL);
        kfree(data);

Surprisingly, there is still no fixup for the probe() function. Why is that? The "..." operator in Coccinelle matches if and only if it matches for all code paths taken. This is to ensure consistency of the modifications. It usually makes a lot of sense, however, this case is an exception. As it is written now, the lower block of the patch says "anything in between is allowed, but then a kfree(data) must follow on all paths". Of course, the probe() routine does not free the structure if all went well because the driver is going to use it. So, the above rule will not match on this path and thus will fail entirely. What is needed here is a "may exist or may not exist" operator. This is, similar to regular expressions, "?". After changing the kfree() line to the following

    ? 	kfree(data);

the meaning of the lower block changes to "anything in between is allowed and kfree(data) may occur later". That implies that, if it occurs, the fix connected to kfree(data) will be applied as well, so finally there is the second match.

Check if clientdata is freed already

When applying this semantic patch to the whole rtc subdirectory, there are a number of fixes, but also false positives, i.e. the pointer has correctly been cleared already by the driver, which is now done twice. To fix this, an alternation can be used again. Like in many languages, an alternation is short-cut if one condition is already met. So the replacing part can be done like this:

    (
        // If this pattern is found, clientdata is set to NULL before data is freed.
        // Do nothing and skip the rest of the alternation
        i2c_set_clientdata(client, NULL);
        ...
        kfree(data);
    |
        // Otherwise apply a fix if kfree() has been found in some code path
        // (doesn't need to be in all paths).
    +	i2c_set_clientdata(client, NULL);
    ? 	kfree(data);
    )

If the first block is met, the driver does the right thing. There still is a match, but no output is produced because no lines are added or removed. If this is not the case, the fix is applied (if needed). While being here, a few drivers clear the pointer after they free the structure. The other way around would be cleaner, so the following snippet is the third alternation:

    +	i2c_set_clientdata(client, NULL);
        kfree(data);
        ...
    -	i2c_set_clientdata(client, NULL);

The final version of the semantic patch is hopefully less frightening:

    @@
    type T;
    identifier client, data;
    @@

    // Check if function uses clientdata
    (
        i2c_set_clientdata(client, data);
    |
        data = i2c_get_clientdata(client);
    |
        T data = i2c_get_clientdata(client);
    )
        // Anything in between is OK
        ...
    (
        // If this pattern is found, clientdata is set to NULL before data is freed.
        // Do nothing and skip the rest of the alternation
        i2c_set_clientdata(client, NULL);
        ...
        kfree(data);
    |
        // If this pattern is found, clientdata is set to NULL after data is freed.
        // Move it to the front and skip the rest of the alternation
    +	i2c_set_clientdata(client, NULL);
        kfree(data);
        ...
    -	i2c_set_clientdata(client, NULL);
    |
        // Otherwise apply a fix if kfree() has been found in some code path
        // (doesn't need to be in all paths).
    +	i2c_set_clientdata(client, NULL);
    ? 	kfree(data);
    )

This matched 96 drivers in 23 directories, changing 213 lines. Note that one really should review those patches afterward. There might be issues which lead to further improvement of the semantic patch. Or there are problematic parts in the source code, but they need to be handled manually. For example, in this patch series, there was once a kfree() missing, so a memory leak was discovered. Also check the Coccinelle output for anomalies. In this case, there are some exceptions regarding "inconsistent control-flow paths". That means, the source code was modified in such a way that code paths outside our match would also be affected. An example is a simple error path in a probe function (excerpt from drivers/gpio/pcf857x.c):

        gpio = kzalloc(sizeof *gpio, GFP_KERNEL);
        if (!gpio)
            return -ENOMEM;

        ... /* set 'status' according to initialization */

        if (status < 0)
            goto fail;  /* clientdata not used yet! */

        ...

        i2c_set_clientdata(client, gpio);

        ...

        status = gpiochip_add(&gpio->chip);
        if (status < 0)
            goto fail;  /* clientdata was modified */

        ...

    fail:
        dev_dbg(...)
        /* 'i2c_set_clientdata(client, NULL)' placed here would be executed for all jumps to 'fail'! */
        kfree(gpio);
        return status;

As seen, a jump to fail can happen after or before clientdata was set to the private data structure. The latter case is outside the scope of the above semantic patch and would still modify its code path. In this example, the change is harmless as clientdata is still NULL and will be set to NULL again, but Coccinelle cannot know and outputs a warning. It is possible to enforce inconsistent changes using the command-line option -allow_inconsistent_paths, but it is marked as dangerous in the help text for a reason. Either triple-check the outcome or just handle the exceptions manually.

Conclusion

The article is meant to incrementally describe the creation of a semantic patch using Coccinelle. While the result is working and the patch series was submitted, be aware that the semantic patch here is primarily meant for educational purposes; more advanced features available in Coccinelle have been left out.

One has to get used to a slightly different way of thinking regarding patches along with learning some new syntax when getting started with Coccinelle. The intention of this article was to demonstrate that it is no major task, though. Once the basic stuff is familiar, semantic patches are easier to understand than scripts with loads of regular expressions. Coccinelle has also been around for some time now and produced a number of useful patch series (available via kernel-janitors), so it is not in alpha stage anymore. In the future, being able to read semantic patches will become increasingly important. Larger tasks, like API changes, might start being done in an automatic fashion. Coccinelle is a handy tool, and trying it out is likely to pay off.

Comments (24 posted)

Using the TRACE_EVENT() macro (Part 2)

In Part 1, the process of creating a tracepoint in the core kernel was explained. This article continues from there with tricks to lower the tracepoint footprint by using the DECLARE_EVENT_CLASS() macro. In addition, the macros used to build the TP_STRUCT__entry fields are described and the TP_printk helper functions are explained.

Saving space by using DECLARE_EVENT_CLASS()

Every tracepoint that is created with the TRACE_EVENT() macro creates several functions that allows perf and Ftrace to interact with the tracepoint automatically. Since these functions have unique prototypes (defined by the TP_PROTO and TP_ARGS macros in the TRACE_EVENT() definition), reference unique structures (defined by the TP_STRUCT__entry macro), assign them uniquely to the ring buffer (as defined by TP_fast_assign), and has a unique way to print out the data (defined in TP_printk), there is very little that the TRACE_EVENT() macro can do to reuse code. That means that every TRACE_EVENT() defined will increase the footprint of the kernel, which is enough to make quite a difference with hundreds of TRACE_EVENT() macros.

        text          data     bss     dec     hex filename
      452114          2788    3520  458422   6feb6 fs/xfs/xfs.o.notrace
      996954         38116    4480 1039550   fdcbe fs/xfs/xfs.o.trace

The XFS filesystem declares over a hundred separate trace events. The data section increased substantially, but that is expected because each event has a corresponding structure with a set of function pointers attached to it. What was not acceptable, though, was that enabling the trace events causes the xfs.o text section to double in size!

That pushed an effort to find a way to condense trace events. The obvious place to start was to have several events, which record the same structured data, share their functions. If two events have the same TP_PROTO, TP_ARGS and TP_STRUCT__entry, there should be a way to have these events share the functions that they use. This was the motivation for the new macro DECLARE_EVENT_CLASS() (originally called TRACE_EVENT_TEMPLATE()) and DEFINE_EVENT().

The DECLARE_EVENT_CLASS() macro has the exact same format as TRACE_EVENT():

   DECLARE_EVENT_CLASS(sched_wakeup_template,

        TP_PROTO(struct rq *rq, struct task_struct *p, int success),

        TP_ARGS(rq, p, success),

        TP_STRUCT__entry(
                __array(        char,   comm,   TASK_COMM_LEN   )
                __field(        pid_t,  pid                     )
                __field(        int,    prio                    )
                __field(        int,    success                 )
                __field(        int,    target_cpu              )
        ),

        TP_fast_assign(
                memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
                __entry->pid            = p->pid;
                __entry->prio           = p->prio;
                __entry->success        = success;
                __entry->target_cpu     = task_cpu(p);
        ),

        TP_printk("comm=%s pid=%d prio=%d success=%d target_cpu=%03d",
                  __entry->comm, __entry->pid, __entry->prio,
                  __entry->success, __entry->target_cpu)
   );

This creates a trace framework that can be used by multiple events. The DEFINE_EVENT() macro is used to create trace events defined by DECLARE_EVENT_CLASS():

   DEFINE_EVENT(sched_wakeup_template, sched_wakeup,
                TP_PROTO(struct rq *rq, struct task_struct *p, int success),
                TP_ARGS(rq, p, success));
   DEFINE_EVENT(sched_wakeup_template, sched_wakeup_new,
                TP_PROTO(struct rq *rq, struct task_struct *p, int success),
                TP_ARGS(rq, p, success));

The example above creates two trace events sched_wakeup and sched_wakeup_new. The DEFINE_EVENT() macro requires 4 parameters:

   DEFINE_EVENT(class, name, proto, args)

• class - the name of the class created with DECLARE_EVENT_CLASS().
• name - the name of the trace event.
• proto - the prototype that is the same as TP_PROTO in the DECLARE_EVENT_CLASS().
• args - the arguments of the prototype that is the same as TP_ARGS in DECLARE_EVENT_CLASS().

Unfortunately, due to the limitations of the C preprocessor, the DEFINE_EVENT() macro needs to repeat the prototype and arguments of the DECLARE_EVENT_CLASS().

Because several of the tracepoints in XFS are very similar, using the DECLARE_EVENT_CLASS() brought down the text and bss size quite substantially.

        text          data     bss     dec     hex filename
      452114          2788    3520  458422   6feb6 fs/xfs/xfs.o.notrace
      996954         38116    4480 1039550   fdcbe fs/xfs/xfs.o.trace
      638482         38116    3744  680342   a6196 fs/xfs/xfs.o.class

To keep the footprint of trace events down, try to consolidate events using the DECLARE_EVENT_CLASS() and DEFINE_EVENT() macros. There is no advantage to using the TRACE_EVENT() macro over the other two. In fact, the TRACE_EVENT() macro is now defined as just:

   #define TRACE_EVENT(name, proto, args, tstruct, assign, print) \
	   DECLARE_EVENT_CLASS(name,			          \
			        PARAMS(proto),		          \
			        PARAMS(args),		          \
			        PARAMS(tstruct),	          \
			        PARAMS(assign),		          \
			        PARAMS(print));		          \
	   DEFINE_EVENT(name, name, PARAMS(proto), PARAMS(args));

Note that the PARAMS macro allows the arguments to contain commas and not be mistaken as multiple parameters of DECLARE_EVENT_CLASS() or DEFINE_EVENT().

TP_STRUCT__entry macros

The first article mentioned the __field and __array macros used to create the structure format of the event that is stored in the ring buffer. The __field(type, item) declared a field in the structure called item of type type (i.e. type item;). The __array(type, item, len) declared a static array called item with len elements of type type (i.e. type item[len];). Those two are the most common, but there are other macros that allow for more complex storage into the ring buffer.

__field_ext(type, item, filter_type)

The __field_ext macro is mainly used for helping the event filter. The event filter (to be discussed in an upcoming article) allows the user to filter events based on the contents of its fields. The type and item are the same as the fields used by __field, the filter_type is an enum. Currently only the following values are used:

• FILTER_OTHER - equivalent to the standard __field() macro.
• FILTER_PTR_STRING - the field points to a string outside the ring buffer.

The FILTER_PTR_STRING and __field_ext are currently only used by the big kernel lock tracepoints. These fields point to the function and file name that contain the tracepoint, which triggers when the big kernel lock is taken or released. This extension is not recommended since it makes the field useless for user-space tools that read the ring buffer in binary format. The big kernel lock tracepoints are an exception because they are currently being used to remove the big kernel lock, so hopefully these tracepoints will be removed from the kernel along with the big kernel lock.

Fields defined by the __field_ext macro are assigned into the ring buffer in TP_fast_assign the same way that fields defined by __field are.

__string(item, src)

The __string macro is used to record a variable length string, which must be null terminated. The first parameter is the name of the field in TP_STRUCT__entry, the second parameter is the source that will fill the string. For example, in the irq_handler_entry tracepoint's TP_STRUCT__entry:

   __string(        name,    action->name    )

The variable action is declared as one of the tracepoint's parameters. The __string macro will allocate enough space in the ring buffer and place the string at the end of the event data. To assign the string in the TP_fast_assign:

   __assign_str(name, action->name);

This will copy the string (action->name) into the reserved space in the ring buffer. To output the string, in TP_printk:

   TP_printk("irq=%d name=%s", __entry->irq, __get_str(name))

The __get_str macro returns a reference to the dynamic string in the __entry structure.

__dynamic_array(type, item, len)

If more control is needed over a dynamic string or variable length array that is not a string, __dynamic_array can be used. The __dynamic_array macro is used to implement the __string macro. It takes three parameters: the type and item are the same as for the __field macro, but the third gives how to determine the length. For example, the block_rq_with_error tracepoint has the following:

   __dynamic_array( char,  cmd,    blk_cmd_buf_len(rq)     )

The call to blk_cmd_buf_len() will determine the length of the array needed to save the data.

To assign a dynamic array field in TP_fast_assign, another macro is needed to get a reference to the array: __get_dynamic_array(item). Note, that since the block_rq_with_error tracepoint defines a dynamic array that is a string, it uses the macro __get_str(item) instead:

   blk_dump_cmd(__get_str(cmd), rq);

The blk_dump_cmd() just fills the cmd array with data determined by the rq variable. The tracepoint can do this because the __get_str macro is defined as:

   #define __get_str(field) (char *)__get_dynamic_array(field)

Either __get_dynamic_array or __get_str can be used in the TP_printk macro to get a reference to the dynamic array.

TP_printk helper functions

There are four TP_printk helper functions, two of which were already described in the previous section (__get_str and __get_dynamic_array). The other two helper functions are more complex and deal with mapping numbers to names.

__print_flags(flags, delimiter, values)

Being able to see the values of flags in a field as symbolic names instead of numbers makes reading a trace much easier. Imagine having to manually parse kmalloc() GFP flags of 0x80d0 instead of GFP_KERNEL|GFP_ZERO.

The first two parameters of the __print_flags are simply the variable that contains the flags (__entry->gfp_flags) and a string delimiter to use between flags if more than one is found ("|"). The delimiter may also be NULL or an empty string (""). The third parameter is an array of structures of the type:

   struct trace_print_flags {
           unsigned long          mask;
           const char             *name;
   };

The module_load tracepoint contains a good example of using __print_flags:

   TP_printk("%s %s", __get_str(name), __print_flags(flags, "",
                      { (1UL << TAINT_PROPRIETARY_MODULE),    "P" },
                      { (1UL << TAINT_FORCED_MODULE),         "F" },
                      { (1UL << TAINT_CRAP),                  "C" })

Depending on which taint flag is set, the corresponding letter ("P", "F", and/or "C") will be displayed. If the value of the flags field is not found within the values parameter, then the value of the flags parameter is converted to a hex string and that is returned. If no bit is set in the flags parameter, then __print_flags returns an empty string. Note that __print_flags internally terminates the values array, so no explicit termination is required.

Alert readers will have noticed that the previous example of the kmalloc GFP flags used a complex bit mask. GFP_KERNEL is not a single bit, but is made up of multiple bits. A mask in values can contain more than one bit. __print_flags will iterate through values, and will use the first match for any particular set of bits. GFP_KERNEL is made up of (__GFP_WAIT | __GFP_IO | __GFP_FS). The kmalloc tracepoint passes in the GFP_KERNEL mask before each of the single bit values. This allows __print_flags to pick the GFP_KERNEL over selecting the individual flags. If one of the three flags that make up GFP_KERNEL was listed in the values before GFP_KERNEL, then the individual flags would be in the output instead of printing GFP_KERNEL. Any remaining flag will also be parsed (as was GFP_ZERO). If bits are still set after all values have been applied, then those bits will show up as a hex number at the end following the delimiter.

__print_symbolic(val, values)

The __print_symbolic function is very similar to __print_flags except that it only produces output for exact matches. The values field is still an array of struct trace_print_flags but the mask must match exactly to val in order to have it print name. If no match is found, val is converted to a hex string, which is returned. No delimiter is needed since only one value is returned by __print_symbolic. Here's an example of its use by the irq tracepoints:

   #define softirq_name(sirq) { sirq##_SOFTIRQ, #sirq }
   #define show_softirq_name(val)                          \
           __print_symbolic(val,                           \
                            softirq_name(HI),              \
                            softirq_name(TIMER),           \
                            softirq_name(NET_TX),          \
                            softirq_name(NET_RX),          \
                            softirq_name(BLOCK),           \
                            softirq_name(BLOCK_IOPOLL),    \
                            softirq_name(TASKLET),         \
                            softirq_name(SCHED),           \
                            softirq_name(HRTIMER),         \
                            softirq_name(RCU))
   [...]
           TP_printk("vec=%d [action=%s]", __entry->vec,
                     show_softirq_name(__entry->vec))

Notice how a helper macro is used to set up the values. This is recommended because macros will be evaluated before they show up in the output format, but functions will not. User-space tools will still be able to parse this because a macro was used rather than a function.

A quick demo

To get a better understanding of what is happening with the events, the following contains some simple usage of event tracing. The examples assume that the user has changed directories to tracing in debugfs (usually, but not always, /sys/kernel/debug/tracing). Also notice that the prompt contains '#' which signifies that these operations require a privileged user:

   [tracing] # echo 1 > events/module/module_load/enable 
   [tracing] # insmod /tmp/taintme.ko 
   [tracing] # insmod /tmp/gpl-nice.ko
   [tracing] # cat trace
   # tracer: nop
   #
   #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
   #              | |       |          |         |
             insmod-1812  [003] 469717.724908: module_load: taintme P
             insmod-1814  [003] 470058.525771: module_load: gpl_nice

The taintme.ko module is a module I wrote that does nothing, but does not have a GPL-compliant license. This causes the "P" taint flag to appear. Notice that no flag appeared for gpl_nice (which, as the name implies, does have a GPL license). Remember, if no bit is set in the flags passed to the __print_flags macro, an empty string is returned.

   [tracing] # echo irq_handler_entry softirq_entry > set_event
   [tracing] # cat trace | head
   # tracer: nop
   #
   #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
   #              | |       |          |         |
             <idle>-0     [002] 470574.178475: irq_handler_entry: irq=26 handler=hpet4
             <idle>-0     [002] 470574.178485: softirq_entry: softirq=1 action=TIMER
             <idle>-0     [002] 470574.178492: softirq_entry: softirq=7 action=SCHED
             <idle>-0     [002] 470574.178495: softirq_entry: softirq=9 action=RCU
             <idle>-0     [000] 470574.178678: irq_handler_entry: irq=35 handler=eth0
             <idle>-0     [000] 470574.178684: softirq_entry: softirq=3 action=NET_RX

Notice that this command used the set_event file to enable tracing. Using this file or the enable file within the events directory act the same way. Because the tracepoint names are (at least so far) unique, just echoing the name into set_event is the equivalent of enabling the tracepoint using events/irq/irq_handler_entry/enable for example. For enabling multiple tracepoints at once it is usually more convenient to use the set_event file, but when activating a singe event, all events in a subsystem, or all events it is more convenient to use the enable files. More details about using the event tracer will be explained in an upcoming article.

The IRQ and soft IRQ events shown above illustrate the output of a dynamic string and use of the __print_symbols helper function. The irq_handle_entry saves the name of the interrupt device (hpet4 and eth0) using a dynamic string to display the name in the trace. The softirq_entry uses the __print_symbols helper function to convert the number of the soft IRQ vector into a matching name that it represents (TIMER, SCHED, RCU, and NET_RX).

Coming in Part 3

Part 3 will look at defining tracepoints outside of the include/trace/events directory (for modules and architecture-specific tracepoints) along with a look at how the TRACE_EVENT() macro does its magic. It will also include some more examples of how the tracepoints are used with Ftrace.

Comments (3 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.34-rc3 . (March 30, 2010)

Core kernel code

• Thomas Gleixner: Run interrupt handlers always with interrupts disabled . (March 26, 2010)

• Mathieu Desnoyers: [RFC PATCH] introduce sys_membarrier(): process-wide memory barrier (another round for v9) . (March 29, 2010)

• Mathieu Desnoyers: create generic alignment api . (March 29, 2010)

• Frederic Weisbecker: Kill the bkl in procfs . (March 30, 2010)

• Srikar Dronamraju: Uprobes patches. . (March 31, 2010)

Device drivers

• Bruno Prémont: hid: new driver for PicoLCD device . (March 25, 2010)

• Joonyoung Shim: PL330: Add PL330 DMA controller driver . (March 25, 2010)

• Todd Fischer: TPS6507x MFD driver . (March 29, 2010)

• Jesse Barnes: Intelligent power sharing driver . (March 29, 2010)

• Elina Pasheva: NET: usb: sierra_net.c driver . (March 29, 2010)

• Andi Kleen: Prevent nested interrupts when the IRQ stack is near overflowing v2 . (March 30, 2010)

• Mark Brown: mfd: Add WM8994 interrupt controller support . (March 30, 2010)

Filesystems and block I/O

• Eric W. Biederman: tagged sysfs support . (March 30, 2010)

• Jeff Layton: cifs: implement multisession mounts (RFC) . (March 30, 2010)

• Valerie Aurora: union mounts: In-kernel copyup v1 . (March 30, 2010)

Memory management

• Andrea Arcangeli: Transparent Hugepage Support #15 . (March 29, 2010)

• Mel Gorman: Memory Compaction v6 . (March 30, 2010)

Networking

• Brandon L Black: Add MSG_WAITFORONE flag to recvmmsg . (March 29, 2010)

• Timo Teras: caching bundles instead of policies . (March 29, 2010)

• James Chapman: l2tp: Introduce L2TPv3 support . (March 29, 2010)

• sjur.brandeland@stericsson.com: net-caif: introducing CAIF protocol stack . (March 30, 2010)

• Jan Engelhardt: nf-next: TEE and nesting . (March 31, 2010)

Architecture-specific

• Viresh KUMAR: Adding Support for SPEAr Platform under ARM architecture . (March 29, 2010)

• Marek Szyprowski: Add support for Aquita board (Samsung S5PC110 based) . (March 29, 2010)

• Hans J. Koch: Add basic support for Telechips TCC8xxx SoCs . (March 29, 2010)

• Anton Vorontsov: Support for Cavium Networks CNS3xxx machines . (March 29, 2010)

• Mika Westerberg: Initial implementation of kdump for ARM . (March 29, 2010)

Security-related

• Andy Lutomirski: Taming execve, setuid, and LSMs . (March 26, 2010)

• Mimi Zohar: EVM . (March 29, 2010)

• Juraj Hlista: audit: Reactive rules . (March 30, 2010)

Virtualization and containers

• Cam Macdonell: Inter-VM shared memory PCI device . (March 29, 2010)

Miscellaneous

• Jonathan Cameron: IIO (Industrial input / output) mailing list. . (March 25, 2010)

Page editor: Jonathan Corbet

Distributions

News and Editorials

Element 1.1 for home theater PCs

Element is a lightweight Linux distribution for use on a home theater PC (HTPC). It comes with most of the same video-playback applications one would find in a modern desktop distribution, but the development team has put considerable effort into wrapping the applications in an environment that is easy to navigate from across the room, and comfortable for non-multimedia-hackers. Tough challenges still remain for any HTPC distribution at the hardware and configuration level, but Element's results are definitely an improvement over basic Linux systems in setup, application integration, and usability.

The distribution project started in April of 2009; the current release is version 1.1, from March 24, 2010. The release is available as a CD-sized ISO image via direct download or Bittorrent. The Element team supports its development through affiliate sales of HTPC hardware, and is pursuing web ad sales and OEM installation deals as additional revenue sources. Element is based on Xubuntu, but with a heavily modified front end. From developers' comments on the support forum, the version of the Xfce desktop environment shipped is stripped down, the xfwm window manager has been replaced by Metacity, the login manager has been replaced by SLiM, and a modified version of the wbar dock/launcher is used to present a simplified interface to launch the main media applications.

Other work has gone into tweaking the settings of the desktop to achieve the "ten-foot interface" designed to make the desktop itself more usable from across the media room. The Metacity window manager uses an add-on called maximus to keep application windows maximized and remove their title bars. The GTK+ and Firefox themes are designed with high-contrast icons and colors, the application fonts are both large and readable, with adequate padding on all sides, a detail that some purely cosmetic widget themes never consider. The desktop panel incorporates easily-accessed corner buttons for volume, application menus, and returning to the desktop.

The interface is very clean, and is consistent across almost all applications. Just as importantly, it starts up quickly and consumes less RAM than a full-sized desktop distribution. The developers claim that it has a lower footprint than standard Xubuntu, and on their test machines takes around 15 seconds to boot up, and requires just 104MB of memory.

At the lower levels, Element retains Xubuntu 9.10's core components: kernel 2.6.31, GCC 4.4.1, X.org 7.4, Xfce 4.6.1, Firefox 3.5, and Python 2.6.4 (which is used for several custom configuration applications). The built-in media offerings include FFmpeg, the XBMC media center front-end, the Transmission Bittorrent client, Decibel audio player, and the VLC, Totem, and GNOME-MPlayer video players.

By default, Element does not install the binary-only NVIDIA graphics card drivers, but they are available for installation through the administration menu. This is important because of two features often discussed in the forums. First, several of the media player applications support GPU-hardware acceleration during playback on NVIDIA hardware, but only when used with the proprietary video drivers. Second, the latest NVIDIA releases finally add Linux support for overscan correction, in which the driver can compensate for edge-cropping that is automatically performed by most consumer TV hardware. Correctly installing and setting up these functions is critical to HTPC users.

Applications, add-ons and desktop usability

Considering that Element ships the same media applications as virtually all HTPC Linux distributions, there are very few surprises to be found. The emphasis is on XBMC, which focuses its feature set on web video playback and local media collections (both on-disc and shared over the local network). The XBMC version included does not have content plugins or scripts installed however; for those the user must visit the XBMC site.

Interestingly, two applications are built-in the program launcher that open proprietary streaming video sites in the browser: YouTube XL and Veoh TV. Both sites can run in full-screen mode, but do not do so by default. At the same time, the Element site offers a small selection of additional apps for manual installation, including the XBMC derivative Boxee, the Moovida media center front-end, and the Hulu Desktop player. Boxee and Moovida both include links to commercial video sources among their built-in shortcuts, and distribution deals may preclude Element from including them in the downloadable ISO image, but the Hulu Desktop player itself is nothing more than a single-site Firefox launcher. Hulu has taken an antagonistic stance towards other ways of connecting viewers to its content, including actively preventing Boxee users from viewing the Hulu site, even though Boxee renders the same content the same way as the Hulu Desktop player — through its browser.

Commercial services aside, web-based and local file-based content are the only content sources covered by Element's applications — there is no DVR functionality, and enabling DVD playback requires fetching an add-on package from the Element site. The Decibel music player supports network shares in addition to local storage, but the emphasis is clearly on providing a rich video environment, not a rich audio environment.

Element users that do enjoy XBMC will appreciate the wbar-based launcher, but others might be surprised to find that it is not user-configurable. Even after installing the Boxee or Hulu Desktop applications, they cannot be added to the launcher without consulting the user forums for tips on locating and altering hidden configuration files.

The missing pieces

All things considered, the usability factor of Element is high. However, on those specific points where it falls short, it can be maddening. For example, in my tests I could not configure Element to use the optical out on my M-Audio audio card, which is connected to the stereo receiver. The card itself was correctly detected, but I could neither enable the correct output, nor even find the appropriate setting to enable it manually. Similarly, I could not get LIRC to recognize my remote control (nor the ancillary front-panel buttons, nor LCD panel output itself). Other users seem to have had success with both tasks, which makes it more frustrating.

Admittedly, LIRC is a pain to configure for everyone, and is probably long overdue for an overhaul. Element is right to discourage the casual user from having high expectations — those interested much fetch the LIRC setup package from the Element web site, then track down missing package dependencies. Likewise, as a MythTV user, I do not expect a new HTPC distro to install and correctly configure a MythTV Backend; it is an arduous and confusing process that continues to throw curve balls even at veterans by changing its configuration in arbitrary ways with each release. MythTV Frontend setup is slightly better, but still should not be done without a browser open for hunting down questions and explanations.

However, the sad truth is that in the present, broadcast TV, cable, and satellite are still where the majority of the video programming in the world comes from. The Boxee team is adamant that Internet video delivery is the wave of the future, and that may be correct, but for the majority of users, a DVR is the critical HTPC component. Omitting one is even ironic in a free software system that supplies numerous avenues for viewing commercial web video, because a DVR's primary purpose is to put the user back in control of when content is viewable.

A few other disappointments popped up during testing — no automatic login, incorrect keyboard detection, etc. — but none so serious that someone who was familiar with the idea of a basic Linux installation could not easily overcome them. Perhaps a bigger issue is that Element's discussion forums are hosted at GetSatisfaction, which does not support full-text searching nor, evidently, allow Google indexing. That borders on unbelievable in 2010.

The future

The Element team is active on the forums, and from their comments a few things are clear about where Element is heading. First, they are aware that the traditional six-month Ubuntu update cycle may not appeal to all HTPC users, and are preparing to base Element 2.0 on the next Long Term Support release of Xubuntu (10.04). Next, they are responsive to users' calls for additional applications. Apparently the approval process for adding additional applications involves Element-specific modifications to the interface to comply with the "ten foot interface" UI guidelines. MythTV may be a possibility, but would require Element collaborating with a MythTV developer for testing.

DVR support is a major undertaking, not just because of MythTV's own peculiarities, but because it means supporting a vast assortment of special-purpose hardware. In contrast, video playback is a software-only problem much smaller in scope. The same can be said of the other major sticking points in Linux HTPC Land: where hardware is concerned, the problem is difficult, whether it is audio configuration, hardware-accelerated video drivers, DVD codecs, or infrared remote control detection and setup. In an ideal world, a distribution would correctly detect all of this hardware and either auto-configure it or step the user through the process. That is still a long way away, but hopefully the community doesn't use that as an excuse for not trying — writing a kernel from scratch isn't simple either, and distributions have made big strides in wireless networking and X configuration recently.

Compared to those tasks, the work involved in building a consistent, easy-to-use HTPC desktop environment may seem like low-hanging fruit. But Element 1.1 is surprisingly good in this regard; a noticeable improvement over the MythTV-centric media distributions. Many choose cosmetically "HTPC like" interfaces, but do not put the same amount of work into window behavior, task switching, application access, and other usability points. It is good to see someone tackling them. Element's low-resource-usage model is also a welcome feature; MeeGo purports to have set-top boxes on its roadmap, but Element is a reminder that a lot of the optimization can be accomplished today. The final word on Element is the same as on other HTPC distributions — your choice must be driven by application support. If you need MythTV, you should look elsewhere. XBMC and Boxee are excellent options for those interested in Internet-accessible video, however, and if you are building a set-top box to run either of those front ends, Element looks like an excellent choice.

Comments (4 posted)

New Releases

The first MeeGo release

The first release of the MeeGo distribution (formerly known as Maemo and Moblin) has been announced; this is also, they say, the beginning of a more open approach to MeeGo development. "What are we opening? The MeeGo distribution infrastructure and the operating system base from the Linux kernel to the OS infrastructure up to the middleware layer. The MeeGo architecture is based on a common core across the different usage models, such as netbooks, handheld, in-vehicle, and connected TV. The MeeGo common core includes the various key subsystems including the core operating system libraries, the comms and telephony services, internet and social networking services, visual services, media services, data management, device services, and personal services." There are downloadable images for Nokia N900 phones and Intel-based netbooks.

Full Story (comments: 5)

openSUSE 11.3 Milestone 4 has been released

Milestone 4 (of 7) for openSUSE 11.3 has been released. This milestone "focuses on switching to upstart as init daemon". Various updated packages are included: OpenOffice 3.2.1 Beta1, NetworkManager 0.8 with better bluetooth and GSM support, Samba version 3.5.1, GNOME 2.30 rc, KDE 4.4.1, and more. "As this is a milestone release, 11.3 milestone 4 does contain bugs that we know about, but should not stand between courageous contributors and release testing." The only bug listed in the announcement is for gwibber. Click below for the full announcement or get a copy and run it.

Full Story (comments: none)

RHEL 5.5 released

Red Hat has released Red Hat Enterprise Linux 5.5. From the release notes: "Highlights of the Red Hat Enterprise Linux 5.5 release include hardware enablement for the Intel Boxboro-EX platform, AMD Magny-Cours processor and IBM Power 7 processor. Virtualization is improved, with support for multiple 10 GigE SR-IOV cards, and automatic usage of hugepages for virtual guest memory when enabled on the system. Interoperability improvements include updates to OpenOffice for Microsoft Office 2007 filters, Samba for Windows 7 compatibility and boot support for virtual machines using Microsoft based PXE services." (Thanks to Scott Dowdle)

Comments (12 posted)

Red Hat Announces Beta Availability of Red Hat Enterprise Virtualization 2.2

Red Hat has announced the beta release of Red Hat Enterprise Virtualization 2.2. "It's been four months since the November 2009 release of Red Hat Enterprise Virtualization for Servers, our new virtualization product that includes a standalone hypervisor based on Kernel-based Virtual Machine (KVM) technology and comprehensive server virtualization management tools. Since then, customers have been deploying Red Hat Enterprise Virtualization as a high-performance, scalable, reliable alternative to other products on the market."

Comments (none posted)

SliTaz 3.0 released

Version 3.0 of SliTaz - a distribution which focuses on working entirely from removable media with low resource usage - has been released. Changes include moving to Midori as the default browser, virtualization with lguest, much faster booting, and, they say, a strong and growing community of contributors. "SliTaz 3.0 has around 2300 packages in the database. A wide variety of packages have been committed and the Tazpkg package manager can now convert deb/rpm/arch/slackware/ipk packages to Slitaz native format (.tazpkg). A lot of time was also spent maintaining professional grade software such as OpenERP, MySQL, GLPI."

Comments (none posted)

Distribution News

Debian GNU/Linux

Bits from the dpkg team

Click below for some bits from the Debian dpkg team. Topics include a call for testers, Team Status and News, Plans and roadmap, Tracking development, Downstreams, Global changes, Documentation, Lots of code refactoring and cleanup, and more.

Full Story (comments: none)

Fedora

Fedora Board Meeting Recap 2010-03-25

Click below for a recap of the March 25, 2010 meeting of the Fedora Advisory Board. Topics include a Trademark matter, Diagram progress, FPL succession, Election schedule, and FESCo Update Policy.

Full Story (comments: none)

SWG Meeting Recap 2010-03-29

Click below for a recap of the March 29, 2010 meeting of the Fedora Board Strategic Working Group. Topics include User Base Diagram Followup, Spins, and Work on the Default Offering.

Full Story (comments: none)

Ubuntu family

Ubuntu 8.10 reaches end-of-life on April 30, 2010

Ubuntu 8.10 "Intrepid Ibex" will reach its end of life April 30, 2010. The supported upgrade path from Ubuntu 8.10 is via Ubuntu 9.04.

Full Story (comments: none)

Distribution Newsletters

DistroWatch Weekly, Issue 347

The DistroWatch Weekly for March 29, 2010 is out. "As the first components of the brand new GNOME 2.30 start to filter through to the project's mirror servers, we are happy to bring you the latest round-up of news and features from the world of free operating systems. This week's lead story is a first-look review of Igelle, an interesting new distribution built from scratch, which includes a brief interview with its creator. In the news section, Oracle makes drastic changes to Solaris licensing, OpenSolaris 2010.03 gets delayed due to show-stopper bugs, Fedora project leader announces resignation, Ubuntu founder explains the reasons behind some of the user interface changes, and Linux Mint development team hints at some of the upcoming new features in the popular distribution. Also in this week's issue, a question and answers section that focuses on complete removal of data from hard disks and a new distribution built from ground up - Cronos Linux. All this and more in this issue of DistroWatch Weekly - happy reading!"

Comments (none posted)

Fedora Weekly News 218

The Fedora Weekly News for March 21, 2010 is out. "On to FWN 218! We start this issue off with announcements including the shiny new Fedora 12 re-spin, which offers updates on this version through March 3, 2010. If you're just starting out with a new install, this will save you at least 550MB in updates over the default install! In Fedora Development announcements, notification to feature owners of the 3/23/10 Beta Freeze for Fedora 13. In news from the Fedora Planet, some outcomes from the recent Marketing Fedora Activity Day (FAD), availability of a new version of Eclipse Linux Tools, and musings on how not to run a community. In Marketing news, many pointers to the recent Marketing FAD activity and outcomes. In Ambassador news, several reports from last week's Chemnitzer Linuxtage 2010, in Chemnitz, Germany. The Quality Assurance beat brings a fresh approach, with coverage on the most recent Test Day, on Fedora 13 changes to disk management, via the udisks (previously DeviceKit-disks) backend and the Palimpsest front end. Also details on Fedora 13 acceptance testing and planning, and details on the new release process wiki documentation. This issue rounds out with Fedora security advisories released in the last week. Please enjoy FWN 218!"

Full Story (comments: none)

openSUSE Weekly News/116

The openSUSE Weekly News for March 27, 2010 is out. Topics include Planet SUSE status, openSUSE 11.3 Milestone 4 release, and much more.

Comments (none posted)

Ubuntu Weekly Newsletter #186

The Ubuntu Weekly Newsletter for March 27, 2010 is out. "In this issue we cover: Mark Shuttleworth: Less is more. But still less, Ubuntu Server Survey 2010 released, Ubuntu One Music Store now in public beta, Ubuntu One Blog: Updates to web contacts, Call for LoCo Council Elections, Launchpad read-only 11.00-13.00 UTC March 31st, 2010, Planning For 10.10 - Growing Our Translations Community, Ubuntu participates in Google Summer of Code, Reviewers Team - Where are we, Ubuntu 10.04 LTS - Free Culture Showcase Winners, Full Circle Magazine #35 & Podcast #3, and much, much more!"

Full Story (comments: none)

Newsletters and articles of interest

Cloudy with a chance of Linux: Canonical aims to cash in (ars technica)

Ryan Paul takes a look at Ubuntu on the server. "As Ubuntu's presence in the server space grows, it is showing up in some unexpected places. Weta Digital, the New Zealand company that did the special effects for Lord of the Rings and some of the 3D rendering for Avatar, reportedly runs Ubuntu on its 35,000-core render farm and virtually all of its desktop computers. The Wikimedia Foundation, the organization behind the popular Wikipedia website, rolled out Ubuntu on 400 of its servers in 2008. We even use Ubuntu ourselves on several of the key servers that power the Ars Orbiting HQ."

Comments (14 posted)

SUSE Studio is powerful OS instance builder (BusinessWeek)

BusinessWeek takes a look at SUSE Studio. "Today, Novell's SUSE Studio is a Web-based virtual appliance/ISO image creator using SUSE Linux. It has no parallels that we can find for building operating systems instances. Novell supplies Studio users with a 15GB online playground to make instances. You're not limited to just CD/DVD results, and you can see the work you've done online - then download it or even execute it online."

Comments (none posted)

Interviews

Interview with Amber Graner

Penelope Stowe interviews Amber Graner, leader of the Ubuntu Women Project. "AG: As the UW Project leader, it is important to me that I stay focused on insuring the direction and goals of the team are kept on track and that we as a group have continually movement. I feel strongly about making sure we have regular reoccurring meetings, helping to identify new goals for each release cycle to accomplish the long-term roadmap goals. I am also focusing on the leadership election process that will take place after UDS-M. I want to make sure the terms, responsibilities, and procedures for these yearly elections are in place. These team elections will help the UW Project identify where we can improve, and help other team members recognize their potential as leaders."

Comments (none posted)

Distribution reviews

Linux on Netbooks Reloads With Ubuntu-based Jolicloud (LinuxPlanet)

LinuxPlanet takes a look at Jolicloud. ""We serve as a hybrid of an operating system and a Web site," [says founder and CEO Tariq Krim]. "The promise of Jolicloud is we want to dissociate the OS from the machine." If you buy one netbook and install Jolicloud, once you connect to the Jolicloud Web site, all your data and apps are backed up. If you purchase a new netbook and sign on to the Jolicloud site on that system, the server synchronizes your new device with all the apps and data from the first machine."

Comments (none posted)

Page editor: Rebecca Sobol

Development

Git-based backup with bup

While Git is aimed at distributed version control for developers, it has also inspired more than a few people to apply Git to backing up all sorts of data. It's been the basis for several backup projects like the outdated eigenclass for general backups, and more specialized hacks to keep track of the etc directory (etckeeper), and a user's home directory (git-home-history). Another noteworthy backup application has popped up recently called bup.

Short for "backup," bup is a fledgling Git-based, or at least Git-inspired, backup solution written in Python and C. The first 0.01 release of bup was announced by Avery Pennarun on January 4, and development has been moving at a pretty good clip since. It is newly licensed under the LGPLv2, and is gathering an active community of developers.

Getting bup and its dependencies

Bup is available via a GitHub repository, and isn't currently packaged for any of the major distributions. The build instructions on the GitHub project page address building on Debian/Ubuntu, though users on Ubuntu 9.10 should substitute python2.6-dev for the development libraries, and make sure to install the python-fuse package to mount bup backups via FUSE.

Users will also want to install the par2 package, which is used by bup's fsck tool to create and read the Par2 format. Par2 allows bup to verify files and to recover damaged files, so if par2 isn't installed, bup's recovery features are not available. When using the bup fsck command, bup creates Par2 files to allow recovery of damaged blocks in the bup index and pack files. Using Par2, bup can recover up to 5% of damaged files. Users who want to test this can use the bup damage command to randomly destroy blocks and then attempt to recover the file using bup fsck.

Pandoc is required to generate bup's documentation, so users who would appreciate man pages and HTML documentation should install the pandoc package as well. Note that bup has no "make install" target at the moment, so the bup documentation and commands need to be moved into the appropriate locations manually.

Making backups with bup

It's important to understand what bup does and doesn't do. Bup is a back-end tool meant to handle large files (like VM images) and incremental backups quickly with as little space as possible. The focus of development is on speed, taking up less space with backups, error recovery, and not so much on being a front-end for performing backups.

This means that bup is not well-suited yet as a standalone solution for creating and managing backups. It's also without a GUI, so bup is best-suited for users who are comfortable writing their own backup scripts and with at least a passing familiarity with Git usage.

Bup is actually a suite of scripts/commands that manage creating backups, indexing files, listing files in a backup, etc. The data is stored in a Git-formatted repository, but bup writes its own packfiles and indexes — it doesn't use the git command directly, it only uses a few of Git's helper programs. The documentation that comes with bup is actually pretty good for a relatively new project, with a man page for each of the commands. It's a bit short on examples and a user guide would be nice, but given the project has only been around since the beginning of the year, it's hard to find fault with the amount of documentation already available.

To create a new backup, a user can either feed a file to bup's split command or use bup index to create an index of files and then use the bup save command to create a new backup. When using split, bup takes input and breaks it into chunks about 8K in size, saving the resulting files in a bup repository.

That's useful, but doesn't actually automate much. Bup index will create or update a cache of files and directories in the filesystem, along with their hashes, which can be used by bup save to track files that have been updated since the last backup. Then bup save can work from the index to create a repository or update it with the files that have changed. Bup supports local and remote backups, bi-directionally. That is to say, bup allows local backups, backing up your local computer to a remote server, or pulling backups to the local machine from a remote server.

Bup is relatively speedy and does a pretty good job of compressing files using Git's packfile format. Bup particularly shines on incremental backups, because it uses a "rolling checksum" to compare the file chunks and only save the parts that have changed. Files are split and then checked into Git separately, and bup creates a index file that lists the filenames of those chunks (from a SH1 hash of the file) in the order that they're created. The files that match don't need to be re-saved. For more detail on the way bup works, see Pennarun's more detailed post about version control of large files that preceded bup's creation.

Restoring from bup backups

It's easier to create backups using bup, at the moment, than actually restoring from backups made with bup. That's not to say it's too challenging to get files, just that the process for restoring files is not as smooth as creating them in the first place. Bup has a save command that can be used to create a backup set, but lacks a restore command. So for the time being, it's best to use bup's split command and use its join utility to retrieve files.

The other problem with trying to use bup save is that it doesn't preserve file data like ownership, links, creation/modification times, etc. The upshot is that files backed up with bup won't have some of the requisite metadata that most users want when restoring from backups.

While bup's incremental backups take up less space than full backups, they still take up space. At the moment, bup has no way to delete older backups or manage the backups in any real way. This means that after a while bup stops being particularly effective at saving space after all.

Users can browse the backups in a number of ways. Bup provides a fuse command for mounting the backups as a directory, and an ftp command for browsing the backups as one would a remote directory via FTP. However, the views do not entirely match up with the actual files. Larger files that have been split are viewed as a top-level directory that has the name of the original file and then sub-directories under that that contain the actual data. Unfortunately, even though it uses Git, bup doesn't actually create a standard Git repository from the backups, so it's not possible to use one of the many GUI tools for Git to browse the backups.

At the moment, bup is relatively primitive but looks to be maturing and gaining interest fairly quickly. The project already has a handful of contributors in addition to Pennarun, and the mailing list seems fairly active for such a new program.

The project doesn't have a roadmap, per se, but discussions on the mailing list indicate that a bup restore command should be a reality soon, as well as handling file metadata so restored files retain their dates, ownership, and so on. While bup isn't yet a full-featured backup system, if the project maintains its current momentum, it should be quite useful by the end of 2010.

Comments (13 posted)

Brief items

GNOME 2.30 has been released

GNOME 2.30 has been released, "on schedule, to the day" after the usual six-month development cycle. As the release notes describe, there are lots of new features for users in 2.30, including a default split view mode for Nautilus, background syncing for Tomboy, easier user management, a time-tracker applet, and much more. There are also new features and bug fixes for developers and in the accessibility framework. "To celebrate this release, a GNOME Store has been created. A selection of t-shirts and mugs is available on this store, that is powered by Zazzle: http://www.zazzle.com/gnome". Click below for the full announcement.

Full Story (comments: 7)

digiKam 1.2.0 released

Version 1.2.0 of the digiKam image editor is out. The biggest change appears to be the multi-threading of many image editing tools and the addition of zoomable preview widgets.

Comments (none posted)

Djigzo 1.3.2

Djigzo is a mail transfer agent whose main purpose in life is to encrypt all email in transit. The 1.3.2 release adds some new configuration options, improved virtual appliance, Debian packages, and more.

Comments (none posted)

What to do with the top-right window space: Esfera

The Ubuntu "Ayatana" mailing list is discussing a proposal from Pablo Quirós for a new user interface element to put in the upper right corner of windows which has been recently vacated on Ubuntu systems. The "Esfera" is a large circle which is used to implement a number of gesture-oriented features; details can be found in this PDF file. "Moved in a semicircle from right to left: the window is turned, and the back of it is shown to the user. The back of a window is a new UI concept... The idea is that we have a 'front' side of a window, which is what we normally see, and a 'back' side, which offers some possibilities that there is no space to display in the front side."

Comments (40 posted)

FusionForge 5.0 released

FusionForge is the project hosting and management system formerly known as GForge, formerly known as SourceForge. The 5.0 release is the result of a determined effort to "upstream" improvements found in various instances. These improvements include rewritten version control integration with support for most version control systems, better security, a multi-host search facility, and more.

Full Story (comments: none)

KDE SC 4.4.2 Released

KDE has released a new version of the KDE Software Compilation (KDE SC). "This month's edition of KDE SC is a bugfix and translation update to KDE SC 4.4. KDE SC 4.4.2 is a recommended upgrade for everyone running KDE SC 4.4.1 or earlier versions. As the release only contains bugfixes and translation updates, it will be a safe and pleasant update for everyone. Users around the world will appreciate that KDE SC 4.4.2 multi-language support is more complete. KDE SC 4 is already translated into more than 50 languages, with more to come."

Full Story (comments: 9)

MongoDB 1.4 released

MongoDB is "a scalable, high-performance, open source, dynamic-schema, document-oriented database." The 1.4 release has been announced; it features a number of performance improvements, better replication support, geospatial search support, a number of query language improvements, and more.

Comments (18 posted)

A pile of Mozilla software releases

Mozilla has released new versions of its applications; as usual, they fix a pile of scary security issues. The releases are: Firefox 3.0.19 and 3.5.9 (3.0.19 being the final planned 3.0.x update), Thunderbird 3.0.4, and SeaMonkey 2.0.4.

Comments (1 posted)

NVIDIA deprecates the xf86-video-nv driver

NVIDIA has posted an announcement to the effect that they are no longer interested in working on the "nv" graphics driver. "Our advice to owners of NVIDIA GPUs running Linux is to use the VESA X driver from the time of Linux distribution installation until they can download and install the NVIDIA Linux driver from their distribution repositories or from nvidia.com." No mention of Nouveau, needless to say.

Full Story (comments: 53)

OpenSSL 1.0.0 released

OpenSSL - an encryption toolkit that many of us have been using for years - has finally announced its 1.0 release. " The OpenSSL project team is pleased to announce the release of version 1.0.0 of our open source toolkit for SSL/TLS. This new OpenSSL version is a major release and incorporates many new features as well as major fixes compared to 0.9.8n." The actual changes listed in the announcement are a real alphabet soup ("Streaming ASN1 encode support for PKCS#7 and CMS"), but it's undoubtedly stuff we all really need to have.

Full Story (comments: 53)

Some new Python database adapters

Back in February, LWN reported that the mess of PostgreSQL adapters for Python might finally be clearing up. So it's with mixed feelings that we note the recent releases of:

• GSQL 0.2.2, an adapter which is focused on "native DBMS access" without using an ODBC layer and "databased objects organised into a tree."

• ceODBC 2.0, a multi-database ODBC adapter with Python 3 support and a number of DBAPI extensions.

• py-postgresql 1.0, a pure Python 3 adapter which, happily, has lost its previous name (py_proboscis).

Comments (none posted)

Silva 2.2 released

Silva is a BSD-licensed content management system based on Zope; its advertised features include "versioning, workflow system, integral visual editor, content reuse, sophisticated access control, multi-site management, extensive import/export facilities, fine-grained templating, and hi-res image storage and manipulation." The 2.2 release is now available; enhancements include improved table of contents management, reworked image and link tools, and quite a bit more.

Full Story (comments: none)

Newsletters and articles

Development newsletters

The following newsletters have been received over the last week:

• Caml Weekly News (March 30).
• GNOME Journal (March 30).
• PostgreSQL Weekly News (March 28).
• TCL-URL! (March 25).

Comments (none posted)

Five questions about building community with Chris Blizzard of Mozilla (opensource.com)

Over at opensource.com, Chris Grams interviews Mozilla's Chris Blizzard about various topics. In five questions, they cover things like how to get involved in a project, what Mozilla's strengths are as a project and community, the role that the project's mission plays, and so on. "If you're interested in helping a project, this is the best thing you can do. Play the part of the generalist, listen a lot, drive change where it's important, and make the biggest difference you can. And always remember: these projects are made up of people, not code, and how you treat others is the most important thing."

Comments (none posted)

Install Multiple 'Bleeding Edge' Firefox Versions in Linux (LXer)

Over at LXer, H. Kwint looks at installing multiple Firefox versions on Linux. He also looks at some features in Firefox 3.7 alpha. "As a last part of my journey into 'bleeding edge' Firefox I wanted to install the 'highly experimental' JaegerMonkey (JM) javascript (js) engine, slated to replace SpiderMonkey in the near future. The story is a bit complex, so here's my short version of it: Firefox comes with a js interpreter called SpiderMonkey - which is slow, and a highly optimizing engine called 'TraceMonkey' which is 'super awesome fast'. However, when something cannot be optimized by 'tracing' by TraceMonkey, Firefox falls back to interpreting using SpiderMonkey, and that's why javascript in Firefox is pretty slow sometimes. The people behind JM hope to solve this by means of 'replacing' the SpiderMonkey interpreter by using Apple Webkits 'Nitro' JIT (Just In Time compiler) instead of interpreting. So, when it makes sense, be 'super awesome fast' by means of tracing, and if not, fall back to 'still really fast' using Nitro."

Comments (none posted)

Walker: GNOME Accessibility Hackfest

Willie Walker has posted a detailed report from the GNOME Accessibility Hackfest. "Some people have suggested that it will be OK if GNOME 3 goes out the door inaccessible, using the analogy that it took GNOME 2 a few releases before it became accessible. I disagree. In my opinion, going out the door inaccessible is a regression and violates the position that accessibility is a core value of GNOME. Having said that, there is a lot of work to do to make GNOME 3 accessible."

Comments (none posted)

Mark Shuttleworth: Less is more. But still less.

In his blog, Mark Shuttleworth writes about removing design elements to reduce clutter on the Ubuntu desktop. "One of the driving mantras for us is 'less is more'. I want us to 'clean up, simplify, streamline, focus' the user experience work that we lead. The idea is to recognize the cost of every bit of chrome, every gradient or animation or line or detail or option or gconf setting. It turns out that all of those extras add some value, but they also add clutter. There's a real cost to them – in attention, in space, in code, in QA. So we're looking for things to strip out, as much (or more) as things to put in."

Comments (31 posted)

Page editor: Jonathan Corbet

Announcements

Non-Commercial announcements

FSF Advocates Free Software for U.S. IPEC Joint Strategic Plan

The Free Software Foundation (FSF) has responded to the United States executive Intellectual Property Enforcement Coordinator (IPEC) Joint Strategic Plan. "The FSF argues that the government should use free software to provide more freedom and transparency to its constituents and reduce the need to engage in costly copyright enforcement activities on behalf of proprietary software companies. The FSF states that "the most egregious harms to the public interest in the areas of copyright and patents come not from a lack of enforcement, but from extraordinarily excessive enforcement.""

Full Story (comments: none)

Commercial announcements

2010 Google Summer of Code applications now being accepted

Google is now accepting applications for the 2010 Summer of Code program. "For our sixth Google Summer of Code, students can choose from 150 Free and Open Source software projects, in technical areas as diverse as gaming to humanitarian efforts to operating system design."

Comments (4 posted)

Sony Playstation to lose Linux installation capability

As described in this Playstation.com weblog entry, the upcoming Playstation v3.21 firmware update will remove the "install other OS" option from the system. "In addition, disabling the 'Other OS' feature will help ensure that PS3 owners will continue to have access to the broad range of gaming and entertainment content from SCE and its content partners on a more secure system." Incidentally, once the firmware update is made, anything on a Linux partition will be immediately lost forever, and not applying the update will cause the system to operate at reduced functionality. This move runs contrary to promises to PS3 owners made in the recent past.

There is a press release in Japanese which can be turned into something resembling English with Google Translate.

Comments (42 posted)

Red Hat Reports Fourth Quarter and Fiscal Year 2010 Results

Red Hat has announced financial results for its fiscal fourth quarter and fiscal year ended February 28, 2010. "Total revenue for the quarter was $195.9 million, an increase of 18% from the year ago quarter. Subscription revenue for the quarter was $169.2 million, up 21% year-over-year. For the full year, total revenue was $748.2 million, an increase of 15% over the prior year, and subscription revenue was $638.7 million, up 18% year-over-year."

Comments (1 posted)

Legal Announcements

Governmental free software preferences are legal in Italy

The Italian constitutional court has ruled that the Piedmont region can legally maintain a preference for free software in its purchasing decisions. According to the court, this preference is for a caratteristica (characteristic) of the software, rather than for a specific product or technology. Click below for the press release (in Italian) from L'Associazione per il Software Libero, or see the English, French, or Spanish versions.

Full Story (comments: 2)

Decision in the SCO Group vs. Novell Jury trial

Novell reports that the jury in the District Court of Utah trial between SCO Group and Novell issued a verdict in favor of Novell. "Novell is very pleased with the jury's decision confirming Novell's ownership of the Unix copyrights, which SCO had asserted to own in its attack on Linux. Novell remains committed to promoting Linux, including by defending Linux on the intellectual property front."

Comments (14 posted)

Elan Seeks to Block Apple Ipad Sales Over Patent (Bloomberg)

The phone-related patent mess is getting deeper: Bloomberg reports that a company called Elan Microelectronics has sued Apple for patent infringement. It seems that Elan owns patent #5,825,352, which discloses the process of detecting two fingers on a touch pad - something nobody would have ever thought of otherwise. "That patent was affirmed after a California district court found Synaptics Inc. infringed that same technology in a 2008 ruling, Elan said." One assumes that Elan does not plan to stop here.

Comments (18 posted)

Articles of interest

Villa: A community of FOSS lawyers?

Luis Villa writes about the emerging FOSS legal community on opensource.com. "Despite all that, the FOSS law community is still growing- which is a testament to the power of the collaborative model. To me, the heart of the test for 'are people a community' is 'can I call on a known group of people for help in a pinch, and would they feel comfortable doing the same of me.' In this informal, unstructured way, there is definitely a growing FOSS legal community of shared interests and relationships."

Comments (11 posted)

Hacker vows to fight Sony PS3 update, restore Linux support (ars technica)

Ars technica reports that hacker George Hotz aims to restore the Other OS option on the PlayStation3. "The wins Hotz has enjoyed in playing with the system were enough to make Sony nervous, and taking away Linux hasn't made many gamers happy. Catching the interest of someone who clearly has both the time and the knowledge to open the system wider isn't likely to end well for Sony; Hotz may not be interested in piracy, but the more capabilities put into the hands of the cracking community the more likely that outcome is going to be. Sony knows just how damaging piracy can be to a platform-the PSP has suffered from that problem almost since launch-but taking away features and claiming security concerns may have simply given the issue more attention than it deserved."

Comments (none posted)

Resources

Linux Foundation Newsletter: March 2010

This issue of the Linux Foundation Newsletter covers Linux.com Store Opens, Design Contest Launches; 2010 Linux.com Gurus Announced; New Program Additions for Collaboration Summit; Call for Participation for LinuxCon Closes March 31; Call for Participation Opens for LinuxCon Japan; 2010 "We're Linux" Video Contest Enters Final Weeks; Linux Foundation in the News; and Upcoming Training Course from Linux Foundation.

Full Story (comments: none)

Blog Postings

O'Reilly: The state of the Internet operating system

Tim O'Reilly has posted a lengthy article about the "Internet operating system." "This is the crux of my argument about the internet operating system. We are once again approaching the point at which the Faustian bargain will be made: simply use our facilities, and the complexity will go away. And much as happened during the 1980s, there is more than one company making that promise. We're entering a modern version of 'the Great Game', the rivalry to control the narrow passes to the promised future of computing. (John Battelle calls them 'points of control'.) This rivalry is seen most acutely in mobile applications that rely on internet services as back-ends."

Comments (none posted)

Education and Certification

Linux Training provided to drive growth of Open Source professionals in Nigeria

The Linux Professional Institute (LPI) has announced that its affiliate organization, LPI-Nigeria, has successfully completed a program of free Linux training for young people. "Lifeforte International High School (Ibadan, Oyo State, Nigeria), the LPI-Nigeria affiliate, has undertaken a two year program of training, Linux Professional Institute Certification (LPIC) exam lab events, and other special initiatives with the country's National Youth Service Corps and government agencies to promote this goal."

Full Story (comments: none)

Meeting Minutes

GNOME Foundation Meeting Minutes Published

The minutes for the March 18, 2010 meeting of the GNOME Foundation are available. Topics include GnuCash automation, Friends of GNOME sysadmin announcement, Annual Report Update, Brazilian GNOME events, The Idlelo Conference, Hackfests, and more.

Full Story (comments: none)

Calls for Presentations

Operating System Platform for Embedded Real-Time applications 2010

Sixth International Workshop on Operating Systems Platforms for Embedded Real-Time Applications (OSPERT 2010) will take place July 6, 2010 in conjunction with the 22nd Euromicro Intl Conference on Real-Time Systems (ECRTS10) in Brussels, Belgium. The call for papers is open until April 4, 2010.

Full Story (comments: none)

Upcoming Events

Linux Users' Group of Davis, April 2010 events

The Linux Users' Group of Davis (LUGOD) will be holding three events this April in Davis, California. There will be a Linux Installfest Workshop April 3, 2010, a social gathering April 6, 2010, and a general meeting April 19, 2010.

Full Story (comments: none)

Events: April 8, 2010 to June 7, 2010

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

Date(s)	Event	Location
April 9 April 11	Spanish DebConf	Coruña, Spain
April 10	Texas Linux Fest	Austin, TX, USA
April 12 April 14	Embedded Linux Conference	San Francisco, CA, USA
April 12 April 15	MySQL Conference & Expo 2010	Santa Clara, CA, USA
April 14 April 16	Linux Foundation Collaboration Summit	San Francisco, USA
April 14 April 16	Lustre User Group 2010	Aptos, California, USA
April 16	Drizzle Developer Day	Santa Clara, CA, United States
April 16 April 17	R/Finance 2010 Conference - 2nd Annual	Chicago, IL, US
April 23 April 25	FOSS Nigeria 2010	Kano, Nigeria
April 23 April 25	QuahogCon 2010	Providence, RI, USA
April 24	Festival Latinoamericano de Instalación de Software Libre	Many, Many
April 24	Open Knowledge Conference 2010	London, UK
April 24 April 25	OSDC.TW 2010	Taipei, Taiwan
April 24 April 25	BarCamb 3	Cambridge, UK
April 24 April 25	Fosscomm 2010	Thessaloniki, Greece
April 24 April 25	LinuxFest Northwest	Bellingham WA, USA
April 24 April 26	First International Workshop on Free/Open Source Software Technologies	Riyadh, Saudi Arabia
April 25 April 29	Interop Las Vegas	Las Vegas, NV, USA
April 28 April 29	Xen Summit North America at AMD	Sunnyvale, CA, USA
April 29	Patents and Free and Open Source Software	Boulder, CO, USA
May 1 May 2	OggCamp	Liverpool, England
May 1 May 2	Devops Down Under	Sydney, Australia
May 1 May 4	Linux Audio Conference	Utrecht, NL
May 3 May 6	Web 2.0 Expo San Francisco	San Francisco, CA, USA
May 3 May 7	SambaXP 2010	Göttingen, Germany
May 6	NLUUG spring conference: System Administration	Ede, The Netherlands
May 7 May 8	Professional IT Community Conference	New Brunswick, NJ, USA
May 7 May 9	Pycon Italy	Firenze, Italy
May 10 May 14	Ubuntu Developer Summit	Brussels, Belgium
May 17 May 21	Fourth African Conference on FOSS and the Digital Commons	Accra, Ghana
May 18 May 21	PostgreSQL Conference for Users and Developers	Ottawa, Ontario, Canada
May 24 May 25	Netbook Summit	San Francisco, CA, USA
May 24 May 26	DjangoCon Europe	Berlin, Germany
May 24 May 30	Plone Symposium East 2010	State College, PA, USA
May 27 May 30	Libre Graphics Meeting	Brussels, Belgium
June 1 June 4	Open Source Bridge	Portland, Oregon, USA
June 3 June 4	Athens IT Security Conference	Athens, Greece

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

Page editor: Rebecca Sobol