LFCS 2012: LLVM and Linux

The LLVM compiler, and its Clang C-family front-end, are getting increasing attention as they mature. At last year's Linux Foundation Collaboration Summit (LFCS), Bryce Lelbach talked about building the kernel with Clang. This year, Mark Charlebois of the Qualcomm Innovation Center (QuIC) picked up where Lelbach left off and, along with his Qualcomm colleague David Kipping, gave a talk at this year's LFCS about LLVM, what its attractions are, and where things stand in building the Linux kernel with Clang.

An introduction to LLVM

Kipping started off with a brief introduction to LLVM, which came from an experiment in compiler construction that Chris Lattner started as part of his PhD. work in 2000. It is a framework for building compilers, rather than a compiler itself. The idea is that components can be assembled into a compiler, and that those components can be reused by other tools. For example, he said, debuggers can use the same parser that the compiler does. But one of the basic premises that underlies LLVM is that no one component is able to serve all of the possible use-cases, so there is no "one true register allocator", no single scheduler, nor a required optimization order in LLVM, he said.

A secondary mission of the LLVM project was to build compilers using the components. "LLVM" is an overloaded term these days, and many use it when they really mean "Clang", Kipping said. LLVM is actually an "umbrella project" with multiple sub-projects.

Clang is the best known of these sub-projects, and is a front-end that supports C, C++, and Objective-C. Clang is known as a fast-to-run compiler, but it is getting slower as more features, optimizations in particular, are added. But it is still a fast compiler, he said. It is designed for conformance with standards and, at least to some extent, compatibility with GCC.

Clang is a strict compiler that is known for the quality of its error messages. It will complain about things that GCC does not, which is part of what led Google to become a "large supporter of LLVM". Google does simultaneous builds of its internal code, using GCC for the code generation and Clang for its static analysis and error/warning messages. By reworking some of the code that Clang was complaining about, Google actually found some "potential problems" in its source code, he said.

Another project under the umbrella is DragonEgg, which is a plug-in that implements a back-end for GCC. That can either provide more GCC compatibility for LLVM code generation or allow one to use GCC language front-ends, like Fortran, that there is no LLVM compiler for. The LLVM debugger (LLDB) is still probably two years away from being ready for production but, because of LLVM's component model, it provides some opportunities for better debugger integration. "Polly" is another area of work for the project. It implements polyhedral optimization, which is an "immature technology" that shows promise for improving the amount of parallelization and vectorization in generated code.

Clang architecture

Clang has a fairly common architecture, with front, middle, and back-ends. It has a "fairly clean" architecture-independent intermediate representation called "Bitcode", though it does have some architecture dependencies, which can cause problems for some back-ends. But, Bitcode can be separated by "space, time, and architecture", so it can be used for code generation at a later time or on a different machine or architecture.

That separability means that Clang can not only be used as a static compiler, but also as JIT compiler. For example, in using Renderscript for Android, developers can package up the Bitcode into the .apk file and the actual code generation is done for the proper target when the app is run for the first time. For example, scalar code would be generated for an ARMv7, but vectorized code would be generated for a Neon core.

LLVM development is "accelerating", Kipping said, with a lot of activity taking place in the last few years. The Android adoption of LLVM for Renderscript in its Honeycomb (3.0) and Qualcomm's contribution of VLIW (very long instruction word) support for LLVM in just the last year or so are some examples he gave of this acceleration. In addition, LLVM is being adopted widely for graphics (e.g. Renderscript, LLVMpipe), parallel programming (e.g. OpenCL), and for things like the Chrome Portable Native Client (PNaCl).

LLVM is also becoming more important in academia. Kipping noted that Lattner gave a keynote speech at the 2012 International Symposium on Code Generation and Optimization, which is one of the most important technical conferences for compiler technology. This year's Proceedings has 103 references to LLVM, which is up from 34 the previous year, he said.

The performance of LLVM's generated code is improving as well. Comparing it to that of GCC, which is the "gold standard today", shows that the LLVM tip is within 1-3% of GCC 4.6 performance for ARM, and within about 4% for x86. The tests need to be re-run for GCC 4.7, he said.

Qualcomm is interested in LLVM because of the "exceedingly complex" nature of ARM system-on-chips (SoCs), with multiple processor cores and multiple graphics pipelines. Code may run on a DSP in one configuration, or on the CPU or GPU in another. The decision on where to run the code may be made based on power saving scenarios. Having a common toolchain that generates code for any of those situations is helpful. In addition, any optimizations that are done in LLVM will be available for multiple code generators, he said.

LLVM is "not there yet" to do complete Linux system builds, Kipping said, which would be a good way to reduce build complexity while getting the advantages of bug fixes and optimizations that have been going into LLVM. Linux is a great source of code that can be used to test and improve LLVM as well. LLVM has a "great community" that is open for participation in various ways including LLVM.org, developer meetings, and conferences. With that, he turned the floor over to Charlebois to talk about LLVM and Linux.

Compiling Linux with Clang

Charlebois began with an explanation of the reasons to build the kernel using Clang. One reason is to get to the point where Clang can be the compiler for the whole system, as Kipping described, and the kernel is a core part of that system. The better diagnostics produced by Clang, which show the actual code where the problem is, are useful, he said. In addition, the kernel uses lots of GCC extensions, which Clang helps find.

The "fix-it" hints that are produced by Clang are very helpful as well because they not only show the problem that produced the warning or error, but also often show how to fix the code. Another area where Clang shines is that it fully expands macros in the diagnostics, which makes it easier to spot problems with macros. Clang has a "still maturing" static analyzer that can show code flow paths. Bringing these kinds of diagnostics to the kernel "will be great", he said.

MINIX has switched to Clang as its default compiler and FreeBSD is working on building its system using Clang. FreeBSD is also using LLVM and KLEE for automatic test generation. LLVM is also being used in graphics applications, like Renderscript for Android and LLVMpipe for Gallium3D. In addition, he noted Sylvestre Ledru's efforts to build Debian with Clang, which LWN also looked at in March.

Most of Charlebois's work on building Linux with Clang focused on cross-compiling for ARM. One of the difficulties he encountered was in finding the right parameters for cross-compilation. The Clang mailing list is very helpful with suggestions, but it is an unsupported configuration and getting all of the flags (e.g. the "triplet") just right can be difficult.

Most of the conversations on the mailing list centered on solving this configuration problem "the right way", which involves a "universal driver" for Clang. That driver would have access to all of the information on the location for the compilers and other tools needed, and users would just point it at a configuration file that specified the target. It's a great idea, he said, but he hasn't seen much movement on it yet.

Another project that he mentioned is ELLCC (Embedded LLVM Compiler Collection), which is a single cross-compiler code base that is based on Clang and LLVM and targets many different architectures (ARM, x86, MIPS, PowerPC, ...). The project has a live web page where you can submit source code, choose a target, and examine the generated code. He said he is "quite impressed" with ELLCC.

Challenges

There are, of course, some challenges building with Clang. Cross-compilation is not a supported configuration, and it is dependent on a GNU cross-toolchain for its assembler and linker. There are lots of warnings produced by Clang which slows down compilation, for example all of the functions that are called (e.g. memcpy()) where the return value is ignored. There are also some bugs in Clang and LLVM for ARM, he said, which he has reported and QuIC has worked on fixing some of them.

The kernel expects to be able to use some GCC behavior that is not supported by Clang. The scripts/Kbuild.include files are GCC-specific, for example. Clang does not have a way to check which options are supported, while GCC does. Clang warns for unused options, but not unsupported ones. In addition, GCC returns false when it it gives an error that there is an unsupported flag, while Clang returns true when it warns about unused flags. There are also "a bunch" of unsupported GCC flags, he said.

There is a master LLVM bug for building the kernel with Clang. The blockers are mostly x86-specific and there are 8-11 of them currently. That bug is a good way to keep track of the status, he said.

The problem with variable-length arrays in structures that Lelbach reported persists. Charlebois patched the kernel to avoid those constructs. It is a non-standard feature of C that is a "GCC-ism", he said. It may come from the fact that GCC supports Ada, so it was probably easy to throw that into C as well.

Explicit register variables are also not supported by Clang, so things like putting the stack pointer into a named variable do not work. In fact, Clang sets the value to null, which doesn't make for a very good stack pointer. Nested functions are also not supported, but they are only present in the Thinkpad driver; since he has been focusing on ARM, he hasn't looked into that.

There are thousands of instances where return values are unused in the kernel, which causes a huge number of warnings when using -Wunused in Clang. It's not desirable to turn off that warning, he said, so he patched around the problem in the kernel. The semantics of the inline keyword for functions is different between GCC's gnu89 and Clang's C99 behavior. There is a gnu89 compatibility flag for Clang, but he has not used it because he wanted to get the kernel to build with Clang's semantics. In addition, EXPORT_SYMBOL() for inline functions makes Clang crash, he said.

There are also missing features or bugs in Clang/LLVM for ARM that he has had to work around. The -mabi-linux flag is not fully supported for Linux. GCC uses four bytes for all enums, while Clang has variable-length enums, which creates incorrect structure offsets, so he doesn't use -mabi-linux in Clang.

64-bit parameter passing requires paired registers in ARM, which is broken in LLVM. There are also problems accessing the upper 32 bits of 64-bit atomic types, which use GCC-specific features to do so in Linux. QuIC has submitted a patch for the first 64-bit problem and is developing one for the second, he said; once they are merged, he can uncomment the affected code in the kernel he is building.

The Clang integrated assembler (IA) is not the default for ARM, because it is still not finished. Finding the right "triplet" for the kernel vs. the one for user-space programs is a problem as "arm-none-linux-gnueabi", for example, works fine for user space, but not for the kernel. Using just "arm" or "armv7" works for the kernel, but gives warnings about not having EABI support. There is also difference in the definition of __kernel_size_t (which is an unsigned long) and size_t (which is defined by Clang to be an unsigned int) which required him to patch the kernel definition to avoid warnings for different argument types for various library functions.

Building

A project has been set up at llvm.linuxfoundation.org that has an automated build framework. It will download the latest LLVM, Clang, QEMU, and the kernel, then patch and build the kernel, and run it in QEMU. It supports the ARM Versatile Express board and Qualcomm's MSM processor, though there is no QEMU target for the MSM, so you can only build for that platform. The Versatile Express boots a 3.3 kernel and runs a toybox user space.

The project site also has Git trees with the patches that he made to the kernel for some of the problems he mentioned earlier. No patches are applied to Clang or LLVM, he said. It is easy to add new architectures to the build framework, and he would love to see people add things like x86, MIPS, and other targets. There is a set of Python tools available to help manage any patches required.

There are still lots of things left to do, of course, and Charlebois wrapped up with his list. First up was to check the status of the problems that Lelbach had reported a year ago. The status of the ARM IA for Clang is also something he needs to look into, as are some of the bugs and problems he mentioned earlier in the talk (inline differences, segment linkage differences, etc.). He would like to build the Linux Test Project with Clang onto a virtual SD card filesystem to use with QEMU and do some regression testing using that. The last item on his list was to set up a test suite for known LLVM bugs so that fixes for those bugs can be detected in newer releases.

It is "pretty exciting" that he can build and run Linux using Clang for one of the ARM architectures, he said. None of the changes that he has made to the kernel stop it from building with GCC, they "just make the kernel less dependent on GCC". He has not tried to merge any of his work upstream, yet, but he hopes that at some point there is interest in making Clang an officially supported compiler for building the kernel. If that happens, he is hopeful that his patches will be helpful in that endeavor.

Comments (30 posted)

GCC and static analysis

Concurrency tends to make programming hard. Kernel development obviously involves dealing with a lot of concurrency, but there is also a lot of multi-threaded user-space development that suffers from the same issues. It would be nice if the computer could help developers avoid race conditions and other problems that arise in concurrent environments. Some developers at Google have been working on just such a project for some time, but they have just relocated the project from GCC to the LLVM Clang compiler, saying that GCC is not suited to the work they want to do. The result has been a sort of wake-up call for GCC developers. Is the GCC compiler suite not well suited to the creation of static analysis tools?

Like kernel programming, multi-threaded user-space programming involves creating and using locks to prevent concurrent access to shared data. In a properly designed and implemented locking scheme, code will never see inconsistent views of shared data, and that data will not change when the code is not expecting changes. Getting to that point is hard, though, and the bugs that result from locking mistakes can be hard to reproduce and hard to diagnose. There are few things more frustrating than a highly intermittent bug that seemingly makes no sense and defies efforts to track it down.

In 2008, Google developer Le-Chun Wu announced a project to add support for "thread safety annotations" in C and C++ programs to the GCC compiler. Since then, work has progressed to the point that the developers have a useful system that is employed by a number of internal projects. The ideas are relatively straightforward. Shared data requiring a lock is annotated with something like:

    Mutex data_mutex;
    struct shared_data Data GUARDED_BY(data_mutex);

Functions that manipulate locks are annotated with:

    class some_class {
  	Mutex mutex;
	void get_lock() EXCLUSIVE_LOCK_FUNCTION(mutex) { ... }
	void put_lock() UNLOCK_FUNCTION(mutex) { ... }
	/* ... */
    };

There are also annotations for shared locks and "trylock" functions that may not succeed. If a function expects a given lock to be held when it is called, it can be annotated with EXCLUSIVE_LOCKS_REQUIRED(); there is also a LOCKS_EXCLUDED() annotation for functions that will acquire non-nesting locks themselves. Finally, this construction can be used for lock ordering constraints:

    class some_class {
	Mutex m1;
	Mutex m2 ACQUIRED_AFTER(m1);
	/* ... */
    };

Some other annotations exist; they can be seen in this slide deck [PDF], which is where your editor stole the above examples from.

The GCC implementation sets itself up as an early optimization pass. It builds a representation of the code from the GIMPLE internal representation, tracking which locks are held at each point through the function. When problems or inconsistencies are found, the compiler raises the alarm, hopefully causing the problem to be fixed before it gets into production code and bites somebody.

This code is available in a branch in the GCC repository and appears to be useful, so it came as a bit of a surprise when, on April 19, Google developer Diego Novillo announced that the project had been terminated, and that the group was now working to implement the same functionality in the LLVM Clang compiler instead. When asked why the group was making this change, developer Delesley Hutchins responded:

The response added that the GCC implementation has "some issues" that would make it hard to merge into the GCC mainline, while the Clang implementation has been in the trunk all along.

The GCC developers, naturally, would like to understand what it is about their compiler that made this project hard. The Google team was hesitant to respond, seemingly unwilling to criticize GCC or to cause a compiler flame war. Eventually, though, Delesley posted a more detailed description of the kinds of difficulties they had run into. There is a lot of information there, but it seems to come down to two crucial points:

• The GIMPLE representation loses information about the structure of the original program that the static analysis pass really needs to have. LLVM, instead, builds an abstract syntax tree that much more closely matches the original C/C++ syntax; additional structures are then based on that tree. LLVM's tree is evidently well suited to the task of static analysis.

• The GIMPLE representation changes significantly from one compiler release to the next, causing a lot of things to break. That adds a maintenance cost that the Google developers are unwilling to pay - especially if basing on LLVM instead makes that cost go away.

There were other things that were better for their purposes in GCC, but, in the balance, the developers concluded that LLVM is the better platform for their work. They seem determined to make the shift and feel that attempts to fix the problems they encountered in GCC would create difficulties elsewhere in the compiler. So this move appears to be a done deal.

In one sense, this decision lacks serious implications for the free software community. LLVM, too, is free software and the static analysis code will be part of it. That said, it is worrisome if GCC's internal structure truly turns out to be poorly suited to static analysis tasks. There is a lot of interesting work being done in the static analysis area; it offers the prospect of finding large numbers of bugs early in the development process. Static analysis tools will almost certainly be an increasingly important part of many developers' tool boxes. If those tools cannot easily be implemented with GCC, that compiler's future may not be as bright as it otherwise should be.

That said, it is dangerous to extrapolate from one project to the whole field of static analysis tools. The GCC plugin mechanism is just beginning to mature; it really has not had the time to turn into a platform that complex tools can be built on top of. So, while this episode is a warning that the GCC developers should hear (and evidently have heard quite well), it should not be seen as evidence of fatal design flaws. Likely as not, it is just an indication of a problem in need of solution - something the GCC community is good at.

Comments (76 posted)

The return of the Unix wars?

Once upon a time, Unix was the up-and-coming operating system that was the future of computing. But something happened on the way to world domination, and, while Unix was certainly a commercial success for many years, it has mostly been supplanted by other things - including Linux. It has often been said that Linux cannot suffer the same fate that brought down Unix, but it is worth thinking about whether that is really true.

Unix had been growing in popularity for many years before its commercial explosion, but the key to its commercial success was a new wave of low-cost workstations that quickly pushed aside centralized minicomputers. These workstations ran an operating system that was, in many cases, nearly identical to the one found on the larger systems, but they were smaller and cheaper, to the point that they could be deployed on the desktops of individual employees. Several vendors jumped into that market and the related market for storage and compute servers.

The problem is that each of those vendors had its own variety of Unix. All of the Unix variants may have had some sort of common heritage, but, by the time they showed up on deployed systems, they were quite different. Heterogeneous networks of Unix-like systems posed challenges for system administrators, developers, and users alike; each new system type brought its own set of quirks, bugs, and misfeatures to deal with. As the various Unix implementations diverged, they became increasingly obnoxious to deal with. As a result, many groups tried to standardize on a single vendor, hoping that they had chosen the right one.

Either that, or they moved to those cheap new PC systems which, at that time, did not run Unix in any convincing way. But they did run DOS (and, eventually, Windows), and, once you got them running, they were all the same. Packaged software became readily available, and, by the mid 1990's, it became increasingly clear that the desktop systems of the future were not going to run Unix. Discouragingly, almost all of the Unix workstation vendors were making deals with Microsoft and announcing that future workstations (and servers) would run NT instead. It was a dark time.

It is fair to say that Linux saved the world from an all-Windows future that was rapidly approaching. Almost since the beginning, though, critics started to say that Linux would fragment just as badly as Unix did; indeed, they predicted that the situation would be even worse. How could things stay coherent, after all, without a benevolent corporate overlord to keep fragmentation from happening?

But that fragmentation did not happen. Lots of distributions exist, but they have all followed roughly the same course and, for the most part, do not differ by all that much. Efforts like the Linux Standard Base and Filesystem Hierarchy Standard have helped in this area. Arguably, a strong focus on avoiding proprietary drivers and basing every distribution on something close to a mainline kernel has helped even more. Moving from one Linux distribution to another can be mildly disorienting for a brief period, but the administration skills are mostly the same, the software still mostly works, and one comes up to speed relatively quickly. Linux has not suffered the fate of proprietary Unix, or even the fragmentation seen in the current free Unix distributions.

But that situation may be changing. An obvious example is Android which, while being based on a Linux kernel, is hardly recognizable as Linux otherwise. Other mobile distributions—MeeGo, Tizen, webOS, etc.—may differ less from "standard" Linux, but they still don't look much like the desktop on which this article is being written. Enterprise distributions increasingly emphasize their own special features - see Oracle's addition of features like Ksplice and Dtrace, for example.

Most recently, we have seen Ubuntu seemingly determined to diverge from other Linux distributions. In particular, the recent announcement that Ubuntu would not move to systemd has led to some charges that they are fragmenting the Linux ecosystem. Such charges do not ring fully true: remember that upstart was there first and was in use by a number of distributions before those distributions (not Ubuntu) switched to something newer and shinier. But, with developments like Unity, Ubuntu does show signs of wanting to be its own world, increasingly removed from the rest of Linux. It is becoming harder for a user of another distribution to sit down at a Ubuntu system and quickly feel at home.

So one could argue that we are heading into a repeat of the Unix wars. It is noteworthy that the word "Linux" does not appear on the ubuntu.com front page; its absence from android.com, instead, has lost its ability to surprise. Distributions were once promoted as a superior form of Linux; now they are given an identity as a separate operating system altogether. Linux, one could say, is just a set of components that a company grabs to build its own special operating system.

That said, there are a couple of things to keep in mind, starting with the fact that the amount of shared code is still high and likely to remain that way. The notable exception, of course, is Android, but that may well be the exception that proves the rule: only a company with the financial resources of Google can hope to take on responsibility for that much code and hope to maintain it over the long term. For most other companies, the cost of going it alone will simply be too high; economics will tend to place an upper limit on how much divergence we will see. That divergence may grow as projects try to do things that Unix-like systems have never done before, but it can also be expected to shrink as the best solutions win and are adopted by others.

The other relevant point is that the computing environment as a whole is becoming far more diverse. A world that was once made up of "desktops" and "servers" now has a far wider variety of computers, most of which are not marketed as such. It seems natural that the Linux that runs on a traditional desktop will be quite different from the Linux that lives on a phone handset, a television, or a logic analyzer. We are not necessarily seeing destructive fragmentation; instead, we're seeing the flexibility of Linux as it easily adapts to a wide range of uses.

In summary: it is probably too soon to declare that the Unix wars have come to Linux. Every Unix was different because vendors felt the need to differentiate their offerings and lock the customer in. Linux vendors, too, are trying to differentiate, but they are doing so (mostly) with free software, which limits how effective such a strategy can be. If Unity truly ends up taking the world by storm, other distributions can ship it overnight. As long as the software remains free, Linux, as a whole, will be as unified as it needs to be.

Comments (38 posted)

A new editor for LWN

We put out a call for applicants for a job as an LWN editor in January, and were quite surprised by all of the excellent responses we received. It took us a while to narrow the list down, but we eventually got there and we are excited to announce that longtime LWN guest author Nathan Willis has accepted our offer to join the staff.

Not surprisingly, based on the great work he has done for us over the last few years, Nate had the right mix of skills and experience for the job. We look forward to him building on those to help LWN expand its coverage and reach over the coming years. Readers undoubtedly already know about his writing, but we asked him to give us a little biographical background; here's what he had to say:

Nate will be starting on April 27 and will quickly be tossed into the fire with trips to two conferences shortly after he starts. Please join us in welcoming Nate to LWN.

We'd also like to thank all of the folks who took the time and effort to apply for the job. There was a long series of hard decisions, which is part of what took us so long. But the result was a good one, and Nate's help will be important in our efforts to make LWN better.

Comments (14 posted)

Quantum random numbers

Good sources of random numbers are sometimes hard to come by. Random numbers need to be, well, random, which is something that random number tests can measure, but they also need to be readily available—in enormous quantities if at all possible. The recently announced Quantum Random Number Generator from the Australian National University (ANU) fits that bill nicely. It is, according to ScienceDaily, the fastest random number generator in the world.

The researchers have derived "true" random numbers by measuring the fluctuations in a quantum vacuum and providing them on a web site for anyone to use. True random numbers are those that come from a completely unpredictable physical process, as opposed to the more frequently encountered pseudo-random numbers generated by computer algorithms. The site describes the measurements used as follows:

The apparatus used is capable of generating 5.7 gigabits of random numbers per second, but the site doesn't stream random bits at that rate due to network bandwidth constraints. As the FAQ points out, there is no actual guarantee that the numbers are truly random, but the statistics (many of which are available on the site) show that the output is "consistent with true randomness". While any measured physical process could have some unexpected bias, the only way to detect such a thing is via statistical measurements of the output. That's true whether you are flipping a coin 5.7 billion times a second or measuring a quantum vacuum.

So what can one do with such a source of (seemingly) true randomness? The ANU researchers have developed a few amusing examples, including a Matrix-like display driven by the random number stream, but there are practical uses as well. While Linux random numbers are generated using an algorithm (thus, pseudo-random), the entropy pool that feeds the algorithm is filled from (hopefully) unpredictable hardware events (e.g. keyboard, mouse, disk, and network). In some cases, especially for servers or embedded devices, many of the sources of entropy are not available. One could conceivably add entropy from a source of true randomness, either locally via a hardware random number generator or by retrieving some bits from afar.

In his "Wielding the ANU Quantum Random Number Generator" blog post, Luke Macken presents some code to use the stream. There are three parts to his quantumrandom project, a command-line tool to retrieve random data, a Python API for use in programs, and a character devices in user space (CUSE) based /dev/qrandom device. The latter will start three threads (by default) to fetch random numbers from the server, which can then be read from the device.

This isn't the first online source of true random numbers, nor will it be the last, presumably. Also, hardware random number generators are becoming more common, though they may not be producing data at anywhere near the rate of the ANU generator. Doing so would likely be serious overkill for a device targeted at a single system anyway.

As Macken points out, though, there is a potential problem lurking in ANU random numbers. Currently, there is no way to get them via an encrypted connection, which means that a man-in-the-middle adversary could gain access to the random bits. Depending on the application, that may not really be a problem. One could certainly take a suitably small random sample from a giant chunk of the random numbers supplied. Of course, choosing the random number for where to take the sample had better not be predictable either. Maybe a simulated lottery draw could help with that.

There is another question that should at least be considered: how trustworthy can random numbers downloaded from a server really be? One hopes that the researchers are on the level, but the security of the server itself may be in question. Since it is difficult to gather a large enough sample to preclude the possibility that some attacker has tampered with the data—by replaying chunks from a big static file of random numbers for example—that possibility exists. The fact that the data "looks" random from the outside is not any kind of guarantee. Caveat "emptor".

Comments (13 posted)

Security quotes of the week

-- Bruce Schneier comments on a US Government Accountability Office report

-- Google ups its security bounties

-- Kim Zetter in Wired

-- Lauren Weinstein on the DNS Charger trojan

Comments (none posted)

Android trojan steals keystrokes using phone movements (ars technica)

This ars technica article looks at a paper [PDF] describing an interesting technique for stealing data input on Android devices. "TapLogger, as their proof-of-concept application for phones running Google's Android operating system is called, masquerades as a benign game that challenges the end user to identify identical icons from a collection of similar-looking images. In the background, the trojan monitors readings returned by the phone's built-in accelerometer, gyroscope, and orientation sensors to infer phone numbers and other digits entered into the device. This then surreptitiously uploads them to a computer under the control of the attackers."

Comments (17 posted)

CERT Linux Triage Tools 1.0 Released

CERT has announced the release of version 1.0 of its "triage tools" for Linux. At its core, it is a Python-based GDB extension called "exploitable" that be used to determine the severity of a given vulnerability.

Comments (3 posted)

asterisk: privilege escalation

Package(s):	asterisk	CVE #(s):	CVE-2012-2414 CVE-2012-2415
Created:	April 25, 2012	Updated:	May 7, 2012
Description:	From the Debian advisory: CVE-2012-2414: David Woolley discovered a privilege escalation in the Asterisk manager interface. CVE-2012-2415: Russell Bryant discovered a buffer overflow in the Skinny driver.
Alerts:	Gentoo 201206-05 asterisk 2012-06-20 Fedora FEDORA-2012-6724 asterisk 2012-05-04 Fedora FEDORA-2012-6612 asterisk 2012-05-03 Debian DSA-2460-1 asterisk 2012-04-25

Comments (none posted)

cobbler: privilege escalation

Package(s):	cobbler	CVE #(s):	CVE-2011-4953
Created:	April 23, 2012	Updated:	April 25, 2012
Description:	From the SUSE advisory: privilege escalation via unsafe call to yaml.load instead of yaml.safe_load
Alerts:	openSUSE openSUSE-SU-2012:0639-1 cobbler 2012-05-25 openSUSE openSUSE-SU-2012:0557-1 cobbler 2012-04-24 SUSE SUSE-SU-2012:0552-1 cobbler 2012-04-23

Comments (none posted)

cobbler: code execution

Package(s):	cobbler	CVE #(s):	CVE-2011-4952 CVE-2011-4954
Created:	April 24, 2012	Updated:	April 25, 2012
Description:	From the openSUSE advisory: Specially crafted YAML could allow attackers to execute arbitrary code due to the use of yaml.load instead of yaml.safe_load.
Alerts:	openSUSE openSUSE-SU-2012:0639-1 cobbler 2012-05-25 openSUSE openSUSE-SU-2012:0557-1 cobbler 2012-04-24

Comments (none posted)

csound: multiple vulnerabilities

Package(s):	csound	CVE #(s):	CVE-2012-2106 CVE-2012-2107 CVE-2012-2108
Created:	April 23, 2012	Updated:	April 25, 2012
Description:	From the Novell bugzilla [1], [2], [3]: [1] csound: buffer overflow in pv_import [2] buffer overflow in lpc_import [3] Stack-based buffer overflow in lpc_import
Alerts:	openSUSE openSUSE-SU-2012:0550-1 csound 2012-04-23

Comments (none posted)

dropbear: code execution

Package(s):	dropbear	CVE #(s):	CVE-2012-0920
Created:	April 25, 2012	Updated:	September 27, 2013
Description:	From the Debian advisory: Danny Fullerton discovered a use-after-free in the Dropbear SSH daemon, resulting in potential execution of arbitrary code. Exploitation is limited to users, who have been authenticated through public key authentication and for which command restrictions are in place.
Alerts:	Gentoo 201309-20 dropbear 2013-09-26 Fedora FEDORA-2012-10934 dropbear 2012-07-29 Mageia MGASA-2012-0205 dropbear 2012-08-12 Debian DSA-2456-1 dropbear 2012-04-24

Comments (none posted)

gallery2: cross-site scripting

Package(s):	gallery2	CVE #(s):	CVE-2012-1113
Created:	April 23, 2012	Updated:	April 25, 2012
Description:	From the CVE entry: Multiple cross-site scripting (XSS) vulnerabilities in the administration subsystem in Gallery 2 before 2.3.2 and 3 before 3.0.3 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors.
Alerts:	Fedora FEDORA-2012-5822 gallery3 2012-04-22 Fedora FEDORA-2012-5832 gallery3 2012-04-22 Fedora FEDORA-2012-5814 gallery2 2012-04-22 Fedora FEDORA-2012-5806 gallery2 2012-04-22

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2012-2123 CVE-2012-2121 CVE-2012-2119
Created:	April 24, 2012	Updated:	December 4, 2013
Description:	From the Red Hat bugzilla [1], [2], [3]: [1] Reported by Steve Grubb, if a process increases permissions using fcaps all of the dangerous personality flags which are cleared for suid apps should also be cleared. Thus programs given priviledge with fcaps will continue to have address space randomization enabled even if the parent tried to disable it to make it easier to attack. (CVE-2012-2123) [2] Currently we do not validate the vector length before calling get_user_pages_fast(), host stack could be easily overflowed by malicious guest driver who gives us a descriptors with length greater than MAX_SKB_FRAGS. A privileged guest user could use this flaw to induce stack overflow on the host with attacker non-controlled data (some bits can be guessed, as it will be pointers to kernel memory) but with attacker controlled length. (CVE-2012-2119) [3] KVM uses memory slots to track and map guest regions of memory. When device assignment is used, the pages backing these slots are pinned in memory using get_user_pages and mapped into the iommu. The problem is that when a memory slot is destroyed the pages for the associated memory slot are neither unpinned nor unmapped from the iommu. The problem is that those pages are now never unpinned and continue to have an increased reference count. This is therefore a potential page leak from the kvm kernel module. (CVE-2012-2121)
Alerts:	Ubuntu USN-2036-1 kernel 2013-12-03 Ubuntu USN-2037-1 EC2 kernel 2013-12-03 Oracle ELSA-2013-1645 kernel 2013-11-26 openSUSE openSUSE-SU-2013:0925-1 kernel 2013-06-10 Debian DSA-2668-1 linux-2.6 2013-05-14 SUSE SUSE-SU-2013:0786-1 Linux kernel 2013-05-14 openSUSE openSUSE-SU-2012:1439-1 kernel 2012-11-05 Ubuntu USN-1577-1 linux-ti-omap4 2012-09-21 Ubuntu USN-1530-1 linux-ti-omap4 2012-08-10 Ubuntu USN-1514-1 linux-ti-omap4 2012-08-10 Ubuntu USN-1529-1 linux 2012-08-10 openSUSE openSUSE-SU-2012:0812-1 kernel 2012-07-03 Oracle ELSA-2012-0862 kernel 2012-07-02 Oracle ELSA-2012-2022 kernel 2012-07-02 Oracle ELSA-2012-2022 kernel 2012-07-02 openSUSE openSUSE-SU-2012:0799-1 kernel 2012-06-28 SUSE SUSE-SU-2012:0789-1 Linux kernel 2012-06-26 Oracle ELSA-2012-2021 kernel 2012-06-23 Oracle ELSA-2012-2021 kernel 2012-06-23 openSUSE openSUSE-SU-2012:0781-1 kernel 2012-06-22 Oracle ELSA-2012-0743 kernel 2012-06-21 Oracle ELSA-2012-2020 kernel 2012-06-21 Ubuntu USN-1471-1 linux-lts-backport-oneiric 2012-06-12 Ubuntu USN-1460-1 linux-ti-omap4 2012-05-31 Ubuntu USN-1459-1 linux-ti-omap4 2012-05-31 Red Hat RHSA-2012:0676-01 kvm 2012-05-21 Red Hat RHSA-2012:0670-01 kernel-rt 2012-05-15 Ubuntu USN-1470-1 linux-lts-backport-natty 2012-06-12 Scientific Linux SL-kvm-20120522 kvm 2012-05-22 Ubuntu USN-1448-1 linux 2012-05-21 Debian DSA-2469-1 linux-2.6 2012-05-10 Ubuntu USN-1473-1 linux 2012-06-13 Ubuntu USN-1457-1 linux 2012-05-31 Fedora FEDORA-2012-6406 kernel 2012-04-26 Fedora FEDORA-2012-6386 kernel 2012-04-24 CentOS CESA-2012:0676 kvm 2012-05-21 Ubuntu USN-1445-1 linux 2012-05-17 Scientific Linux SL-kern-20120619 kernel 2012-06-19 CentOS CESA-2012:0743 kernel 2012-06-19 Ubuntu USN-1476-1 linux-ti-omap4 2012-06-15 Red Hat RHSA-2012:0743-01 kernel 2012-06-18 Ubuntu USN-1474-1 linux-ti-omap4 2012-06-13 Ubuntu USN-1472-1 linux 2012-06-12 Ubuntu USN-1453-1 linux-ec2 2012-05-25 Ubuntu USN-1452-1 linux 2012-05-25 Oracle ELSA-2012-0676 kvm 2012-05-22 Ubuntu USN-1455-1 linux-lts-backport-oneiric 2012-05-29

Comments (none posted)

mozilla: multiple vulnerabilities

Package(s):	firefox, thunderbird	CVE #(s):	CVE-2012-0467 CVE-2012-0470 CVE-2012-0471 CVE-2012-0477 CVE-2012-0479
Created:	April 25, 2012	Updated:	July 23, 2012
Description:	From the CVE entries: Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox 4.x through 11.0, Firefox ESR 10.x before 10.0.4, Thunderbird 5.0 through 11.0, Thunderbird ESR 10.x before 10.0.4, and SeaMonkey before 2.9 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors. (CVE-2012-0467) Heap-based buffer overflow in the nsSVGFEDiffuseLightingElement::LightPixel function in Mozilla Firefox 4.x through 11.0, Firefox ESR 10.x before 10.0.4, Thunderbird 5.0 through 11.0, Thunderbird ESR 10.x before 10.0.4, and SeaMonkey before 2.9 allows remote attackers to cause a denial of service (invalid gfxImageSurface free operation) or possibly execute arbitrary code by leveraging the use of "different number systems." (CVE-2012-0470) Cross-site scripting (XSS) vulnerability in Mozilla Firefox 4.x through 11.0, Firefox ESR 10.x before 10.0.4, Thunderbird 5.0 through 11.0, Thunderbird ESR 10.x before 10.0.4, and SeaMonkey before 2.9 allows remote attackers to inject arbitrary web script or HTML via a multibyte character set. (CVE-2012-0471) Multiple cross-site scripting (XSS) vulnerabilities in Mozilla Firefox 4.x through 11.0, Firefox ESR 10.x before 10.0.4, Thunderbird 5.0 through 11.0, Thunderbird ESR 10.x before 10.0.4, and SeaMonkey before 2.9 allow remote attackers to inject arbitrary web script or HTML via the (1) ISO-2022-KR or (2) ISO-2022-CN character set. (CVE-2012-0477) Mozilla Firefox 4.x through 11.0, Firefox ESR 10.x before 10.0.4, Thunderbird 5.0 through 11.0, Thunderbird ESR 10.x before 10.0.4, and SeaMonkey before 2.9 allow remote attackers to spoof the address bar via an https URL for invalid (1) RSS or (2) Atom XML content. (CVE-2012-0479)
Alerts:	openSUSE openSUSE-SU-2014:1100-1 Firefox 2014-09-09 Gentoo 201301-01 firefox 2013-01-07 Mageia MGASA-2012-0176 iceape 2012-07-21 Debian DSA-2457-2 iceweasel 2012-05-13 Mandriva MDVSA-2012:081 firefox 2012-05-24 Debian DSA-2464-2 icedove 2012-05-08 Ubuntu USN-1430-3 thunderbird 2012-05-04 Debian DSA-2464-1 icedove 2012-05-03 SUSE SUSE-SU-2012:0580-1 Mozilla Firefox 2012-05-02 Ubuntu USN-1430-2 ubufox 2012-04-27 Ubuntu USN-1430-1 firefox 2012-04-27 openSUSE openSUSE-SU-2012:0567-1 firefox, thunderbird, seamonkey, xulrunner 2012-04-27 Mandriva MDVSA-2012:066 mozilla 2012-04-27 Oracle ELSA-2012-0516 thunderbird 2012-04-25 Oracle ELSA-2012-0515 firefox 2012-04-25 Oracle ELSA-2012-0515 firefox 2012-04-25 Scientific Linux SL-fire-20120425 firefox 2012-04-25 Scientific Linux SL-thun-20120425 thunderbird 2012-04-25 CentOS CESA-2012:0516 thunderbird 2012-04-25 CentOS CESA-2012:0516 thunderbird 2012-04-24 CentOS CESA-2012:0515 firefox 2012-04-25 CentOS CESA-2012:0515 firefox 2012-04-25 Red Hat RHSA-2012:0516-01 thunderbird 2012-04-24 Red Hat RHSA-2012:0515-01 firefox 2012-04-24 Debian DSA-2458-1 iceape 2012-04-24 Debian DSA-2457-1 iceweasel 2012-04-24 Ubuntu USN-1430-4 apparmor 2012-06-12 SUSE SUSE-SU-2012:0688-1 MozillaFirefox 2012-06-02

Comments (none posted)

mozilla: multiple vulnerabilities

Package(s):	firefox, thunderbird	CVE #(s):	CVE-2012-0468 CVE-2012-0469 CVE-2012-0472 CVE-2012-0473 CVE-2012-0474 CVE-2012-0478
Created:	April 25, 2012	Updated:	June 13, 2012
Description:	From the CVE entries: The browser engine in Mozilla Firefox 4.x through 11.0, Thunderbird 5.0 through 11.0, and SeaMonkey before 2.9 allows remote attackers to cause a denial of service (assertion failure and memory corruption) or possibly execute arbitrary code via vectors related to jsval.h and the js::array_shift function. (CVE-2012-0468) Use-after-free vulnerability in the mozilla::dom::indexedDB::IDBKeyRange::cycleCollection::Trace function in Mozilla Firefox 4.x through 11.0, Firefox ESR 10.x before 10.0.4, Thunderbird 5.0 through 11.0, Thunderbird ESR 10.x before 10.0.4, and SeaMonkey before 2.9 allows remote attackers to execute arbitrary code via vectors related to crafted IndexedDB data. (CVE-2012-0469) The cairo-dwrite implementation in Mozilla Firefox 4.x through 11.0, Firefox ESR 10.x before 10.0.4, Thunderbird 5.0 through 11.0, Thunderbird ESR 10.x before 10.0.4, and SeaMonkey before 2.9, when certain Windows Vista and Windows 7 configurations are used, does not properly restrict font-rendering attempts, which allows remote attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code via unspecified vectors. (CVE-2012-0472) The WebGLBuffer::FindMaxUshortElement function in Mozilla Firefox 4.x through 11.0, Firefox ESR 10.x before 10.0.4, Thunderbird 5.0 through 11.0, Thunderbird ESR 10.x before 10.0.4, and SeaMonkey before 2.9 calls the FindMaxElementInSubArray function with incorrect template arguments, which allows remote attackers to obtain sensitive information from video memory via a crafted WebGL.drawElements call. (CVE-2012-0473) Cross-site scripting (XSS) vulnerability in the docshell implementation in Mozilla Firefox 4.x through 11.0, Firefox ESR 10.x before 10.0.4, Thunderbird 5.0 through 11.0, Thunderbird ESR 10.x before 10.0.4, and SeaMonkey before 2.9 allows remote attackers to inject arbitrary web script or HTML via vectors related to short-circuited page loads, aka "Universal XSS (UXSS)." (CVE-2012-0474) The texImage2D implementation in the WebGL subsystem in Mozilla Firefox 4.x through 11.0, Firefox ESR 10.x before 10.0.4, Thunderbird 5.0 through 11.0, Thunderbird ESR 10.x before 10.0.4, and SeaMonkey before 2.9 does not properly restrict JSVAL_TO_OBJECT casts, which might allow remote attackers to execute arbitrary code via a crafted web page. (CVE-2012-0478)
Alerts:	openSUSE openSUSE-SU-2014:1100-1 Firefox 2014-09-09 Gentoo 201301-01 firefox 2013-01-07 Ubuntu USN-1430-3 thunderbird 2012-05-04 SUSE SUSE-SU-2012:0580-1 Mozilla Firefox 2012-05-02 SUSE SUSE-SU-2012:0688-1 MozillaFirefox 2012-06-02 Ubuntu USN-1430-2 ubufox 2012-04-27 Ubuntu USN-1430-1 firefox 2012-04-27 openSUSE openSUSE-SU-2012:0567-1 firefox, thunderbird, seamonkey, xulrunner 2012-04-27 Mandriva MDVSA-2012:066 mozilla 2012-04-27 Fedora FEDORA-2012-6622 xulrunner 2012-04-27 Fedora FEDORA-2012-6622 firefox 2012-04-27 Oracle ELSA-2012-0516 thunderbird 2012-04-25 Oracle ELSA-2012-0515 firefox 2012-04-25 Oracle ELSA-2012-0515 firefox 2012-04-25 Scientific Linux SL-fire-20120425 firefox 2012-04-25 Scientific Linux SL-thun-20120425 thunderbird 2012-04-25 CentOS CESA-2012:0516 thunderbird 2012-04-25 CentOS CESA-2012:0516 thunderbird 2012-04-24 CentOS CESA-2012:0515 firefox 2012-04-25 CentOS CESA-2012:0515 firefox 2012-04-25 Red Hat RHSA-2012:0516-01 thunderbird 2012-04-24 Red Hat RHSA-2012:0515-01 firefox 2012-04-24 Ubuntu USN-1430-4 apparmor 2012-06-12

Comments (none posted)

mysql: multiple vulnerabilities

Package(s):	mysql-5.1, mysql-dfsg-5.0, mysql-dfsg-5.1	CVE #(s):
Created:	April 24, 2012	Updated:	April 25, 2012
Description:	Multiple security issues were discovered in MySQL. See the MySQL documentation for version 5.1.62 and version 5.0.96.
Alerts:	Ubuntu USN-1427-1 mysql-5.1, mysql-dfsg-5.0, mysql-dfsg-5.1 2012-04-24

Comments (none posted)

openssl: exploitable vulnerability

Package(s):	openssl	CVE #(s):	CVE-2012-2110
Created:	April 19, 2012	Updated:	May 10, 2012
Description:	A rather unhelpful description from the OpenSSL advisory: A potentially exploitable vulnerability has been discovered in the OpenSSL function asn1_d2i_read_bio. Any application which uses BIO or FILE based functions to read untrusted DER format data is vulnerable. Affected functions are of the form d2i_*_bio or d2i_*_fp, for example d2i_X509_bio or d2i_PKCS12_fp.
Alerts:	Oracle ELSA-2014-0626 openssl097a and openssl098e 2014-06-05 Oracle ELSA-2014-0626 openssl097a and openssl098e 2014-06-05 Gentoo 201312-03 openssl 2013-12-02 Oracle ELSA-2013-0587 openssl 2013-03-05 openSUSE openSUSE-SU-2013:0336-1 openssl 2013-02-25 SUSE SUSE-SU-2012:1149-2 compat-openssl097g 2012-09-18 SUSE SUSE-SU-2012:1149-1 compat-openssl097g 2012-09-12 SUSE SUSE-SU-2012:0674-1 openssl 2012-05-30 Fedora FEDORA-2012-6395 openssl 2012-05-10 Oracle ELSA-2012-2011 openssl 2012-05-08 Fedora FEDORA-2012-6403 openssl 2012-04-27 Oracle ELSA-2012-0518 openssl 2012-04-25 Oracle ELSA-2012-0518 openssl 2012-04-25 Scientific Linux SL-open-20120425 openssl 2012-04-25 CentOS CESA-2012:0518 openssl 2012-04-25 CentOS CESA-2012:0518 openssl 2012-04-25 Red Hat RHSA-2012:0522-01 openssl 2012-04-25 Red Hat RHSA-2012:0518-01 openssl 2012-04-24 Ubuntu USN-1424-1 openssl 2012-04-19 Debian DSA-2454-1 openssl 2012-04-19 Mandriva MDVSA-2012:060 openssl 2012-04-19 SUSE SUSE-SU-2012:0623-1 openssl 2012-05-16 SUSE SUSE-SU-2012:0637-1 openssl 2012-05-23

Comments (none posted)

openssl: exploitable vulnerability

Package(s):	openssl0.9.8	CVE #(s):	CVE-2012-2131
Created:	April 24, 2012	Updated:	April 25, 2012
Description:	From the Mandriva advisory: It was discovered that the fix for CVE-2012-2110 [an exploitable vulnerability] was not sufficient to correct the issue for OpenSSL 0.9.8.
Alerts:	SUSE SUSE-SU-2012:1149-2 compat-openssl097g 2012-09-18 SUSE SUSE-SU-2012:1149-1 compat-openssl097g 2012-09-12 SUSE SUSE-SU-2012:0674-1 openssl 2012-05-30 Ubuntu USN-1428-1 openssl 2012-04-24 Debian DSA-2454-2 openssl 2012-04-24 Mandriva MDVSA-2012:064 openssl0.9.8 2012-04-24 SUSE SUSE-SU-2012:0623-1 openssl 2012-05-16 SUSE SUSE-SU-2012:0637-1 openssl 2012-05-23

Comments (none posted)

php5: directory traversal attack

Package(s):	php5	CVE #(s):	CVE-2012-1172
Created:	April 23, 2012	Updated:	July 2, 2012
Description:	From the openSUSE advisory: Scripts that accept multiple file uploads in a single request were potentially vulnerable to a directory traversal attack.
Alerts:	SUSE SUSE-SU-2013:1351-1 PHP5 2013-08-16 Gentoo 201209-03 php 2012-09-23 CentOS CESA-2012:1046 php 2012-07-10 Scientific Linux SL-php-20120709 php 2012-07-09 Scientific Linux SL-php5-20120705 php53 2012-07-05 Scientific Linux SL-php-20120705 php 2012-07-05 Oracle ELSA-2012-1046 php 2012-06-30 Oracle ELSA-2012-1047 php53 2012-06-28 Oracle ELSA-2012-1045 php 2012-06-28 CentOS CESA-2012:1047 php53 2012-06-27 CentOS CESA-2012:1045 php 2012-06-27 Red Hat RHSA-2012:1047-01 php53 2012-06-27 Red Hat RHSA-2012:1046-01 php 2012-06-27 Red Hat RHSA-2012:1045-01 php 2012-06-27 SUSE SUSE-SU-2012:0604-1 PHP5 2012-05-09 Mandriva MDVSA-2012:071 php 2012-05-10 SUSE SUSE-SU-2012:0598-2 PHP5 2012-05-09 SUSE SUSE-SU-2012:0598-1 PHP5 2012-05-09 Debian DSA-2465-1 php5 2012-05-09 Fedora FEDORA-2012-6911 php-eaccelerator 2012-05-07 Fedora FEDORA-2012-6907 php-eaccelerator 2012-05-07 Fedora FEDORA-2012-6911 maniadrive 2012-05-07 Fedora FEDORA-2012-6907 maniadrive 2012-05-07 Fedora FEDORA-2012-6911 php 2012-05-07 Fedora FEDORA-2012-6907 php 2012-05-07 Mandriva MDVSA-2012:065 php 2012-04-27 openSUSE openSUSE-SU-2012:0551-1 php5 2012-04-23 Ubuntu USN-1481-1 php5 2012-06-19

Comments (none posted)

quagga: multiple vulnerabilities

Package(s):	quagga	CVE #(s):	CVE-2012-0249 CVE-2012-0250 CVE-2012-0255
Created:	April 23, 2012	Updated:	September 14, 2012
Description:	From the CVE entries: Buffer overflow in the ospf_ls_upd_list_lsa function in ospf_packet.c in the OSPFv2 implementation in ospfd in Quagga before 0.99.20.1 allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a Link State Update (aka LS Update) packet that is smaller than the length specified in its header. (CVE-2012-0249) Buffer overflow in the OSPFv2 implementation in ospfd in Quagga before 0.99.20.1 allows remote attackers to cause a denial of service (daemon crash) via a Link State Update (aka LS Update) packet containing a network-LSA link-state advertisement for which the data-structure length is smaller than the value in the Length header field. (CVE-2012-0250) The BGP implementation in bgpd in Quagga before 0.99.20.1 does not properly use message buffers for OPEN messages, which allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a message associated with a malformed Four-octet AS Number Capability (aka AS4 capability). (CVE-2012-0255)
Alerts:	Gentoo 201310-08 quagga 2013-10-10 Scientific Linux SL-quag-20120913 quagga 2012-09-13 Scientific Linux SL-quag-20120913 quagga 2012-09-13 Oracle ELSA-2012-1259 quagga 2012-09-13 Oracle ELSA-2012-1258 quagga 2012-09-13 CentOS CESA-2012:1259 quagga 2012-09-12 CentOS CESA-2012:1258 quagga 2012-09-12 Red Hat RHSA-2012:1259-01 quagga 2012-09-12 Red Hat RHSA-2012:1258-01 quagga 2012-09-12 Ubuntu USN-1441-1 quagga 2012-05-15 Debian DSA-2459-2 quagga 2012-05-04 Debian DSA-2459-1 quagga 2012-04-26 Fedora FEDORA-2012-5436 quagga 2012-04-22 Fedora FEDORA-2012-5411 quagga 2012-04-22

Comments (none posted)

typo3-src: cross-site scripting

Package(s):	typo3-src	CVE #(s):	CVE-2012-2112
Created:	April 23, 2012	Updated:	April 25, 2012
Description:	From the Debian advisory: Helmut Hummel of the typo3 security team discovered that typo3, a web content management system, is not properly sanitizing output of the exception handler. This allows an attacker to conduct cross-site scripting attacks if either third-party extensions are installed that do not sanitize this output on their own or in the presence of extensions using the extbase MVC framework which accept objects to controller actions.
Alerts:	Debian DSA-2455-1 typo3-src 2012-04-20

Comments (none posted)

wicd: local privilege escalation

Package(s):	wicd	CVE #(s):	CVE-2012-2095
Created:	April 24, 2012	Updated:	April 25, 2012
Description:	From the Fedora advisory: The wicd daemon suffered from a local privilege escalation flaw due to incomplete input sanitization. A local attacker sould use this to inject arbitrary code through the D-Bus interface.
Alerts:	Gentoo 201206-08 wicd 2012-06-21 Fedora FEDORA-2012-5923 wicd 2012-04-24 Fedora FEDORA-2012-5909 wicd 2012-04-24

Comments (none posted)

wireshark: multiple vulnerabilities

Package(s):	wireshark	CVE #(s):	CVE-2012-1595 CVE-2012-1596
Created:	April 19, 2012	Updated:	April 25, 2012
Description:	From the Red Hat Bugzilla [1, 2]: CVE-2012-1595: An integer underflow, subsequently leading to request to allocate a large amount of memory was found in the way pcap and pcap-ng file parsers of Wireshark, a network traffic analyzer, processed Extension and / or Multi-Channel header information in ERF files. A remote attacker could provide a specially-crafted packet capture file (with size of full pseudoheader being greater than the packet size), which once opened by a local unsuspecting user would lead to wireshark executable abort. CVE-2012-1596: A memory allocation flaw was found in the way the MP2T dissector of Wireshark, a network traffic analyzer, processed capture files containig invalid pointer values used for packet length specification. A remote attacker could provide a specially-crafted packet capture file (causing unsigned length value to be reduced by more than its value, resulting into it being a very large value and attempt to allocate large amount of memory when reassembling the packet tvbuff to the requested length), which once opened by a local unsuspecting user would lead to wireshark executable abort.
Alerts:	Oracle ELSA-2013-1569 wireshark 2013-11-26 openSUSE openSUSE-SU-2012:0558-1 wireshark 2012-04-25 CentOS CESA-2012:0509 wireshark 2012-04-24 Oracle ELSA-2012-0509 wireshark 2012-04-23 Scientific Linux SL-wire-20120423 wireshark 2012-04-23 Red Hat RHSA-2012:0509-01 wireshark 2012-04-23 Fedora FEDORA-2012-5243 wireshark 2012-04-19 Fedora FEDORA-2012-5256 wireshark 2012-04-19

Comments (none posted)

wireshark: multiple vulnerabilities

Package(s):	wireshark	CVE #(s):	CVE-2012-1593 CVE-2012-1594
Created:	April 19, 2012	Updated:	April 25, 2012
Description:	From the Red Hat Bugzilla [1, 2]: CVE-2012-1593: A NULL pointer dereference flaw was found in the way ANSI A dissector of the Wireshark, a network traffic analyzer, processed certain capture files (those causing wireshark to pass NULL packet information via a global variable to the call_dissector() routine). A remote attacker could provide a specially-crafted packet capture file, which once opened by a local unsuspecting user would lead to wireshark executable crash. CVE-2012-1594: A denial of service flaw was found in the way IEEE 802.11 dissector of Wireshark, a network traffic analyzer, processed certain capture files (16-bit integers were used as counters during loading of capture files for certain protocols). A remote attacker could provide a specially-crafted packet capture file, which once opened by a local unsuspecting user would lead to situation, where wireshark executable would never finish loading of such capture file (infinite loop).
Alerts:	openSUSE openSUSE-SU-2012:0558-1 wireshark 2012-04-25 Fedora FEDORA-2012-5243 wireshark 2012-04-19

Comments (none posted)

Kernel release status

The current development kernel is 3.4-rc4, released on April 21. Linus says: "But none of it really looks all that scary. It looks like the 3.4 release is all on track, but please do holler if you see regressions." There are some reports of ongoing difficulties with the Nouveau graphics driver; hopefully those will be sorted out soon.

Stable updates: the 3.0.29, 3.2.16, and 3.3.3 stable kernel updates were released on April 22. With 3.2.16, Greg Kroah-Hartman will stop producing 3.2 updates, but Ben Hutchings has stated his intent to pick up and continue maintenance for this kernel for some time yet.

The 3.0.30 and 3.3.4 updates are in the review process as of this writing; they can be expected on or after April 26.

Comments (none posted)

Quotes of the week

-- Rob Landley

-- Matt Mackall

-- Tejun Heo

Comments (none posted)

An Interview With Linus Torvalds (TechCrunch)

TechCrunch has an interview with Linus Torvalds. "Would some kernel people prefer getting tucked in at night instead of being cursed at? I’m sure that would be appreciated. I don’t think I have it in me, though."

Comments (54 posted)

git.kernel.org mirror at Google

Google has announced that it has put up a (read-only) git.kernel.org mirror at kernel.googlesource.com. "kernel.googlesource.com is served out of multiple Google data centers, utilizing facilities in Asia, the United States and Europe to provide speedy access from almost anywhere in the world." (Thanks to several LWN readers).

Comments (20 posted)

O_HOT and O_COLD

While storage devices are billed as being "random access" in nature, the truth of the matter is that operations to some parts of the device can be faster than operations to others. Rotating storage has a larger speed differential than flash, while hybrid devices may show a large difference indeed. Given that differences exist, it is natural to want to place more frequently-accessed data on the faster part of the device. But a recent proposal to allow applications to influence this placement has met with mixed reviews; the problem, it seems, is a bit more complicated than it appears.

The idea, as posted by Ted Ts'o, is to create a couple of new flags to be provided by applications at the time a file is created. A file expected to be accessed frequently would be created with O_HOT, while a file that will see traffic only rarely would be marked with O_COLD. It is assumed that the filesystem would, if possible, place O_HOT files in the fastest part of the underlying device.

The implementation requires a change to the create() inode operation; a new parameter is added to allow the VFS layer to pass down the flags passed by the application. That change is the most intrusive part of the patch, requiring tweaks to most filesystems—43 files changed in all. The only filesystem actually implementing these flags at the outset is, naturally, ext4. In that implementation, O_HOT files will be placed in low-numbered blocks, while O_COLD files occupy the high-numbered blocks—but only if the filesystem is stored on a rotating device. Requesting O_HOT placement requires the CAP_RESOURCE privilege or the ability to dip into the reserved block pool.

A lot of people seem to like the core idea, but there were a lot of questions about the specifics. What happens when the storage device is an array of rotating devices? Why assume that a file is all "hot" or all "cold"; some parts of a given file may be rather hotter than others. If an application is using both hot and cold files, will the (long) seeks between them reduce performance overall? What about files whose "hotness" varies over time? Should this concept be tied into the memory management subsystem's notion of hot and cold pages? And what do "hot" and "cold" really mean, anyway?

With regard to the more general question, Ted responded that, while it would be possible to rigorously define the meanings of "hot" and "cold" in this context, it's not what he would prefer to do:

In other words, this proposal seems well suited to the needs of, say, a large search engine company that is trying to get the most out of its massive array of compute nodes. That is certainly a valid use case, but a focus on that case may make it hard to generalize the feature for wider use.

Generalizing the feature may also not be helped by placing the decision on who can mark files as "hot" at the individual filesystem level. That design could lead to different policies provided by different filesystems; indeed, Ted expects that to happen. Filesystem-level policy will allow for experimentation, but it will push the feature further into an area where it is only useful for specific applications where the developers have full control over the underlying system. One would not expect to see O_HOT showing up in random applications, since developers would have no real way to know what using that flag would do for them. And that, arguably, is just as well; otherwise, it would not be surprising to see the majority of files eventually designated as "hot."

Interestingly, there is an alternative approach which was not discussed here. In 2010, a set of "data temperature" patches was posted to the btrfs list. This code watched accesses to files and determined, on the fly, which blocks were most in demand. The idea was that btrfs could then migrate the "hot" data to the faster parts of the storage device, improving overall performance. That work would appear to have stalled; no new versions of those patches have appeared for some time. But, for the general case, it would stand to reason that actual observations of access patterns would be likely to be more accurate than various developers' ideas of which files might be "hot."

In summary, it seems that, while there is apparent value in the concept of preferential treatment for frequently-accessed data, figuring out how to request and implement that treatment will take some more time. Among other things, any sort of explicit marker (like O_HOT) will quickly become part of the kernel ABI, so it will be difficult to change once people start using it. So it is probably worthwhile to ponder for a while on how this feature can be suitably designed for the long haul, even if some hot files will have to languish in cold storage in the meantime.

Comments (12 posted)

Toward a safer fput()

Locking and the associated possibility of deadlocks are a challenge for developers working anywhere in the kernel. But that challenge appears to be especially acute in the virtual filesystem (VFS) layer, where the needs of many collaborating subsystems all come together in one place. The difficulties inherent in VFS locking were highlighted recently when the proposed IMA appraisal extension ran into review problems. The proposed fix shows that, while these issues can be worked around, the solution is not necessarily simple.

The management of file structure reference counts is done with calls to fget() and fput(). A file structure, which represents an open file, can depend on a lot of resources: as long as a file is open, the kernel must maintain its underlying storage device, filesystem, network protocol information, security-related information, user-space notification requests, and more. An fget() call will ensure that all of those resources stay around as long as they are needed. A call to fput(), instead, might result in the destruction of any of those resources. For example, closing the last file on an unmounted filesystem will cause that filesystem to truly go away.

What all this means is that a call to fput() can do a lot of work, and that work may require the acquisition of a number of locks. The problem is that fput() can also be called from any number of contexts; there are a few hundred fput() and fput_light() calls in the kernel. Each of those call sites has its own locking environment and, usually, no knowledge of what code in other subsystems may be called from fput(). So the potential for problems like locking-order violations is real.

The IMA developers ran into exactly that sort of problem. The IMA appraisal cleanup code is one of those functions that can be invoked from an arbitrary fput() call. That code, it seems, sometimes needs to acquire the associated inode's i_mutex lock. But the locking rules say that, if both i_mutex and the task's mmap_sem are to be acquired, i_mutex must be taken first. If somebody calls fput() with mmap_sem held—something that happens in current kernels—the ordering rule will be violated, possibly deadlocking the system. A deadlocked system is arguably secure, but IMA users might be forgiven for complaining about this situation anyway.

To get around this problem, IMA tried to check for the possibility of deadlock inside fput(), and, in that case, defer the underlying __fput() call (which does the real work) to a later and safer context. This idea did not impress VFS maintainer Al Viro, who pointed out that there is no way to encode all of the kernel's locking rules into fput(). In such situations, it can be common for core kernel developers to say "NAK" and get back to what they were doing before, but Al continued to ponder the problem, saying:

After thinking for a bit, he came up with a plan that offered a way out. Like the scheme used by IMA, Al's idea involves turning risky fput() calls into an asynchronous operation running in a separate thread. But there is no knowledge of locking rules added to fput(); instead, the situation is avoided altogether whenever possible, and all remaining calls are done asynchronously.

In particular, Al is looking at all callers of fget() and fput() to see if they can be replaced with fget_light() and fput_light() instead. The "light" versions have a number of additional requirements: they come close to requiring that the calling code run in atomic context while the reference to the file structure is held. For a lot of situations - many system calls, for example - these rules don't get in the way. As the name suggests, the "light" versions are less expensive, so switching to them whenever possible makes sense regardless of any other issues.

Then, fput() in its current form is renamed to fput_nodefer(). A new fput() is added that, when the final reference to a file is released, queues the real work to be done asynchronously later on. The "no defer" version will obviously be faster—the deferral mechanism will have a cost of its own—so its use will be preferred whenever possible. In this case, "whenever possible" means whenever the caller does not hold any locks. That is a constraint that can be independently verified for each call site; the "no defer" name should also hopefully serve as a warning for any developer who might change the locking environment in the future.

With luck, all of the performance-critical calls can be moved to the "no defer" version, minimizing the performance hit that comes from the deferral of the fput() call. So it seems like a workable solution—except for one little problem pointed out by Linus: deferral can change the behavior seen by user space. In particular, the actual work of closing a file may not be complete by the time control returns to user space, causing the process's environment to differ in subtle and timing-dependent ways. Any program that expects that the cleanup work will be fully done by the time a close() call returns might just break.

That does not seem like a good outcome either. The good news is that there is a potential solution out there in the form of Oleg Nesterov's task_work_add() patch set. This patch adds a functionality similar to workqueues, but with a fundamental difference: the work is run in the context of the process that was active at the time the work is added.

In brief, the interface defines work to be done this way:

    #include <linux/task_work.h>

    typedef void (*task_work_func_t)(struct task_work *);

    struct task_work {
	struct hlist_node hlist;
	task_work_func_t func;
	void *data;
    };

The task_work structure can be initialized with:

    void init_task_work(struct task_work *twork, task_work_func_t func, 
		        void *data);

The work can be queued for execution with:

    int task_work_add(struct task_struct *task, struct task_work *twork, 
		      bool notify);

A key aspect of this interface is that it will run any queued work before returning to user space from the kernel. So that work is guaranteed to be done before user space can run again; in the case of a function like close(), that guarantee means that user space will see the same semantics it did before, without subtle timing issues. So, Linus suggested, this API may be just what is needed to make the new fput() scheme work.

There is just one final little problem: about a half-dozen architectures lack the proper infrastructure to support task_work_add() properly. That makes it unsuitable for use in the core VFS layer. Unless, of course, you're Al Viro; in that case it's just a matter of quickly reviewing all the architectures and coming up with a proposed fix—perhaps in assembly language—for each one. Assuming Al's work passes muster with the architecture maintainers, all of this work is likely to be merged for 3.5 - and the IMA appraisal work should be able to go in with it.

Comments (6 posted)

A library for seccomp filters

Now that it is looking like Linux will be getting an enhanced "secure computing" (seccomp) facility, some are starting to turn toward actually using the new feature in applications. To that end, Paul Moore has introduced libseccomp, which is meant to make it easier for applications to take advantage of the packet-filter-based seccomp mode. That will lead to more secure applications that can permanently reduce their ability to make "unsafe" system calls, which can only be a good thing for Linux application security overall.

Enhanced seccomp has taken a somewhat tortuous path toward the mainline—and it's not done yet. Will Drewry's BPF-based solution (aka seccomp filter or seccomp mode 2) is currently in linux-next, and recent complaints about it have been few and far between, so it would seem likely that it will appear in the 3.5 kernel. It will provide fine-grained control over the system calls that the process (and its children) can make.

What libseccomp does is make it easier for applications to add support for sandboxing themselves by providing a simpler API to use the new seccomp mode. By way of contrast, Kees Cook posted a seccomp filter tutorial that describes how to build an application using the filters directly. In addition, it is also interesting to see that the recent OpenSSH 6.0 release contains support for seccomp filtering using a (pre-libseccomp) patch from Drewry. The patch limits the privilege-separated OpenSSH child process to a handful of legal system calls, while setting up open() to fail with an EACCESS error

As described in the man pages that accompany the libseccomp code, the starting point is to include seccomp.h, then an application must call:

    int seccomp_init(uint32_t def_action);

The def_action parameter governs the default action that is taken when a system call is rejected by the filter. SCMP_ACT_KILL will kill the process, while SCMP_ACT_TRAP will cause a SIGSYS signal to be issued. There are also options to force rejected system calls to return a certain error (SCMP_ACT_ERRNO(errno)), to generate a ptrace() event (SCMP_ACT_TRACE(msg_num)), or to simply allow the system call to proceed (SCMP_ACT_ALLOW).

Next, the application will want to add its filter rules. Those rules can apply to any invocation of a particular system call, or it can restrict calls to only use certain values for the system call arguments. So, a rule could specify that write() can only be used on file descriptor 1, or that open() is forbidden, for example. The interface for adding rules is:

    int seccomp_rule_add(uint32_t action,
                         int syscall, unsigned int arg_cnt, ...);

The action parameter uses the same action macros as are used in seccomp_init(). The syscall argument is the system call number of interest for this rule, which could be specified using __NR_syscall values, but it is recommended that the SCMP_SYS() macro be used to properly handle multiple architectures. The arg_cnt specifies the number of rules that are being passed; those rules then follow.

In the simplest case, where the rule is just allowing a system call for example, there are no argument rules. So, if the default action is to kill the process, adding a rule to allow close() would look like:

    seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(close), 0);

Doing filtering based on the system call arguments relies on a set of macros that specify the argument of interest by number (SCMP_A0() through SCMP_A5()), and the comparison to be done (SCMP_CMP_EQ, SCMP_CMP_GT, and so on). So, adding a rule that allows writing to stderr would look like:

    seccomp_rule_add(SCMP_ACT_ALLOW, SCMP_SYS(write), 1, 
                     SCMP_A0(SCMP_CMP_EQ, STDERR_FILENO));

Once all the rules have been added, the filter is loaded into the kernel (and activated) with:

    int seccomp_load(void);

The internal library state that was used to build the filter is no longer needed after the call to seccomp_load(), so it can be released with a call to:

    void seccomp_release(void);

There are a handful of other functions that libseccomp provides, including two ways to extract the filter code from the library:

    int seccomp_gen_bpf(int fd);
    int seccomp_gen_pfc(int fd);

Those functions will write the filter code in either kernel-readable BPF or human-readable Pseudo Filter Code (PFC) to fd. One can also set the priority of system calls in the filter. That priority is used as a hint by the filter generation code to put higher priority calls earlier in the filter list to reduce the overhead of checking those calls (at the expense of the others in the rules):

    int seccomp_syscall_priority(int syscall, uint8_t priority);

In addition, there are a few attributes for the seccomp filter that can be set or queried using:

    int seccomp_attr_set(enum scmp_filter_attr attr, uint32_t value);
    int seccomp_attr_get(enum scmp_filter_attr attr, uint32_t *value);

The attributes available are the default action for the filter (SCMP_FLTATR_ACT_DEFAULT, which is read-only), the action taken when the loaded filter does not match the architecture it is running on (SCMP_FLTATR_ACT_BADARCH, which defaults to SCMP_ACT_KILL), or whether PR_SET_NO_NEW_PRIVS is turned on or off before activating the filter (SCMP_FLTATR_CTL_NNP, which defaults to NO_NEW_PRIVS being turned on). The NO_NEW_PRIVS flag is a recent kernel addition that stops a process and its children from ever being able to get new privileges (via setuid() or capabilities for example).

The last attribute came about after some discussion in the announcement thread. The consensus on the list was that it was desirable to set NO_NEW_PRIVS by default, but allow libseccomp users to override that if desired. Other than some kudos from other developers about the project, the only other messages in the thread concerned the GPLv2 license. Moore said that the GPL was really just his default license and, since it made more sense for a library to use the LGPL, he was able to get the other contributors to agree to switch to the LGPLv2.1

While it is by no means a panacea, the seccomp filter will provide a way for applications to make themselves more secure. In particular, programs that handle untrusted user input, like the Chromium browser which was the original impetus for the feature, will be able to limit the ways in which damage can be done through a security hole in their code. One would guess we will see more applications using the feature via libseccomp. Seccomp mode 2 is currently available in Ubuntu kernels, and is slated for inclusion in ChromeOS—with luck we'll see it in the mainline soon too.

Comments (6 posted)

Mageia nears its second release

The Mageia distribution was formed in September 2010 when a group of former Mandriva employees combined forces with motivated community members to fork the software and form a non-profit association to manage the distribution and its assets. The project founders cited a lack of faith in the faltering Mandriva S.A. company, which had recently laid off much off the development team. As we discussed last week, the state of Mandriva is still unclear, while Mageia made its first stable release in June 2011, and is now nearing its second.

Software

Gauging the health of an open source project is a tricky undertaking. Oliver Burger recently announced that the release schedule for Mageia 2, would be pushed back, with a final release now slated for May 15th. To some that would indicate cause for concern, but to be fair even large and well-established projects occasionally slip on their release schedule, as happens frequently with Fedora.

In the announcement, the revised Mageia 2 schedule was described as the result of outstanding bugs resulting from migration to systemd for initialization and dracut for initial ramdisk creation, as well as usability changes to the DrakX installer. Moving to systemd and dracut will bring Mageia more in line with Red Hat and Fedora, which should simplify packaging and development for the smaller project in the long run. The very first Mandrake release was based on Red Hat, back in 1998, and the distribution remains roughly compatible in other respects (including use of RPM as the package format). On the packaging front, though, Mageia also chose to embrace RPM 4.x, while Mandriva took to the rival RPM 5.

While the original Mandrake shipped with KDE in place of GNOME as the desktop environment, a distinction still maintained in the latest Mandriva release, Mageia offers both. The latest development build for Mageia 2 (beta 3, released April 18), is provided as a live CD in both GNOME and KDE versions, for both 32-bit and 64-bit architectures, and in five different language packs covering distinct regions of the globe. If that is not enough options, there are also three DVD ISO images (each of which includes KDE, GNOME, and LXDE): one for 32-bit systems, one for 64-bit, and one with both.

Beta 3 ships with kernel 3.3.1, KDE 4.8.2, and GNOME 3.2, which puts it slightly behind in its GNOME packages. There was talk of migrating to Grub 2 and btrfs as well, but both moves appear to have been pushed back until after Mageia 2. There are also several outstanding issues regarding video driver support (detailed in the Mageia 2 errata).

I tested the GNOME version of beta 3 (since I am more familiar with GNOME) on a 32-bit system. Although I was bitten by the video driver bug described in the errata, the desktop experience is snappy, and Mageia provides a good, well-rounded GNOME 3 experience. The live CD version includes most of the same standbys you will find in any contemporary distribution: Firefox 10 (the extended support release), LibreOffice 3.5.2.2, Evolution, Empathy, and so on.

Mageia does differentiate itself by offering its own system and configuration tools, derived from Mandriva. They do a better job than most distributions of presenting configuration options in human-readable form (e.g., "Set up a new network interface" rather than "Network Manager"), although die-hards might object to the pervasive use of the word "administrator" in place of "root." The Rpmdrake software-update tool is also unique to the Mandriva heritage; it is a tree-view driven installer and update manager akin to most others, but it also separates applications into multiple levels of categorization and allows you to filter updates based on whether they are security fixes, bugfixes, or general updates, and to distinguish between GUI applications, non-GUI applications, and metapackages.

Governance and community

Perhaps a better way to assess how a new distribution is getting along is to look at the vitality of its community and contributor pool. On this front, Mageia appears to be in good shape. The distribution hosts both mailing lists and web discussion forums for users, as well as the typical IRC option and a number of developer-team-specific mailing lists. Both the forum and community list are active — there are about 1500 registered forums users, and the list tends to generate on-topic threads that involve multiple active parties. That is in contrast with the scenario we have all seen from time to time when one or two people tend to dominate every discussion.

But although the list traffic is healthy, one thing does stand out about it. Even on the mageia-discuss list, which is "about Mageia general discussions: future plans, community, association, ...", development discussions account for the bulk of the traffic. Installer issues, casual bug reports, build notes, and debates over package selection are commonplace. What this suggests is that Mageia's user community is still largely composed of developers and packagers, rather than end-users. This is a good indicator that the contributor pool is motivated and engaged, but it also indicates that the distribution has yet to break through to the mainstream public.

The mageia-dev list is even higher traffic, particularly package maintainers push updates in preparation for the Mageia 2 release. The project's organization is interesting; it has an elected board that takes responsibility for the governance of the non-profit foundation and overall mission-and-direction questions, and a separate community council in charge of planning, coordination, and production. Board members are elected to one-year terms, but the seats on the community council are filled by three representatives from each team (development, packaging, QA, documentation, translation, infrastructure, etc). There are currently 13 members.

That governance model is in the minority among large, established distributions. OpenSUSE, Fedora, and Ubuntu all include corporate appointees in their governing bodies. Debian does not, naturally, as it does not have a corporate sponsor, but its technical committee is charged primarily with technical policy duties, and can only overrule a developer decision by a 75% majority vote. Mageia's board and council appear to function rather casually, as befits a young project. Dispute resolution and major technical crises have yet to strike the distribution in a big way (although there were decisions to be made leading up to the Mageia 1 release) — but if history teaches anything about open source projects, the disputes will come.

Mageia's founders wanted to insulate the distribution against business concerns that would endanger the future of the software product itself — with good reason, considering the recent financial woes on Mandriva's side. But a small distribution needs more than legal protection to make itself successful in the marketplace. As a result, Mageia's recent moves to bring the distribution back in line with the system stack used by its RPM-based contemporaries are just as important as its community structure; they make development more sustainable by relying on healthy upstream projects, rather than expending limited resources on roll-your-own components.

Comments (1 posted)

Distribution quotes of the week

-- Toshio Kuratomi

-- Mark Shuttleworth

Comments (1 posted)

Fedora architecture promotion requirements adopted

After extensive discussion, the Fedora Project has adopted a set of requirements that must be met before a secondary architecture can be promoted to primary status. More discussion has inevitably followed; the most controversial item seems to be the requirement that the architecture must support installation with Anaconda.

Comments (16 posted)

Red Hat Announces the Beta Release of RHEL 6.3

Red Hat has released a beta of Red Hat Enterprise Linux 6.3. For details see the technical notes on the changes and the release notes.

Comments (none posted)

Scientific Linux 5.8

Scientific Linux 5.8 has been released. "We want to thank all those who have contributed helping us build and test this release. Finding bugs early has helped make this an excellent release." As usual the release notes contain additional details.

Comments (none posted)

The new Minty Swift Linux is now available

The Swift Linux distribution aims for a lightweight and user-friendly experience with good support for older hardware. Version 0.2.0 uses the Linux Mint Debian Edition (LMDE) as a base and comes in several editions: Regular Swift, Diet Swift, Taylor Swift, Minnesota Swift, Chicago Swift, and Silicon Valley Swift.

Full Story (comments: none)

Fedora 18 Release name voting and poll

The Fedora Project has opened the voting to decide the code name for Fedora 18. There is also a poll on whether releases should have code names at all. "This cycle, the Board is also asking contributors to let us know if we should continue to have release names for future Fedora releases. Even though the interface is the same, this portion is intended to be a poll rather than a straight up vote. The Fedora Board will look at the answers to determine if enough contributors value continuing to create release names to make it worthwhile in the future. If it does seem desirable, the Board will likely look into forming a working group to come up with a new method for creating release names for future releases."

Full Story (comments: 51)

Distribution newsletters

• DistroWatch Weekly, Issue 453 (April 23)
• Fedora Weekly News Issue 293 (mid-April)
• Maemo Weekly News (April 23)
• Ubuntu Weekly Newsletter, Issue 262 (April 22)

Comments (none posted)

People behind Debian: Samuel Thibault

Raphaël Hertzog interviews Samuel Thibault about his work on accessibility and the Hurd. "The Debian GNU/Hurd port can almost completely be installed from the official mirrors, using the standard Debian Installer. Some patches need some polishing, but others are just waiting for being uploaded… Debian GNU/Hurd can start a graphical desktop and run office tools such as gnumeric, as well as the iceweasel graphical web browser, KDE applications thanks to Pino Toscano’s care, and GNOME application thanks to Emilio Pozuelo Monfort’s care. Of course, general textmode hacking with gcc/make/gdb/etc. just works smoothly. Thanks to recent work on ghc and ada by Svante Signell, the archive coverage has passed 76%."

Comments (11 posted)

Shuttleworth: Quality has a new name

Here's the traditional naming post from Mark Shuttleworth; the next Ubuntu release will be code-named Quantal Quetzal. Various other bits of information can be found there as well: "Rumours and allegations of a move from Upstart to SystemD are unfounded: Upstart has a huge battery of tests, the competition has virtually none. Upstart knows everything it wants to be, the competition wants to be everything. Quality comes from focus and clarity of purpose, it comes from careful design and rigorous practices. After a review by the Ubuntu Foundations team our course is clear: we’re committed to Upstart, it’s the better choice for a modern init, innit."

Those who are interested can also read Lennart Poettering's response.

Comments (276 posted)

The first Calligra release

Calligra was formally announced as KDE's successor to the KOffice office suite in December of 2010. Now, just under 18 months later, the project has labeled its first stable release version 2.4, signifying continuity with the old version numbering scheme that terminated with 2.3. The code is substantially different, however — there are brand new applications and major components from earlier generations were rewritten. On top of that, the suite is available in special builds for two portable platforms.

What's in the box

Calligra is officially branded an "application suite" — not an "office suite." It is a fair distinction to insist upon, as Calligra combines the traditional office suite programs (word processor, spreadsheet, and presentation builder) with creative graphics programs (both raster and vector), and a growing collection of harder-to-categorize tools (such as a project planning application and a note-taker). As a refresher, the bulk of the code that formed the initial Calligra suite came from KOffice. There was an unfortunate split between the maintainers of several key applications and the chief maintainer of the KWord component (who also happened to maintain the KOffice shared library).

When it became clear that the differences were taking KWord in a different direction than the rest of the suite, the others decided to head off on their own. The KDE project voted to bless Calligra as the way forward, and the new name dropped the "Office" moniker entirely to open the door for non-productivity-tool projects to join in the effort. The core "office" applications were renamed: Calligra Words, Calligra Sheets, and Calligra Stage.

As you might expect in light of the philosophical differences with KWord, the Calligra Words application has been rewritten substantially. The release notes highlight a completely new text layout engine, but also emphasize that the interface is designed to be a smooth continuation of the old KWord experience. Nevertheless, Calligra Words is not quite as mature as the Calligra Sheets and Calligra Stage components (though it is perfectly acceptable for the vast majority of office document projects). All three applications use the ODF format common to LibreOffice and Apache OpenOffice, although Calligra does not implement as much of the specification as either of the older projects.

Joining the big three in the "office" category is the GUI database front-end Kexi. I must confess that I have never quite been the target user for a GUI database application, but Kexi is a seasoned player in this field. Two new applications debut in the 2.4 office collection: Calligra Flow, a diagramming and flowcharting tool, and Braindump, a "note taking" application. The "graphics" category includes two established applications: the painting and raster-editing tool Krita, and the vector editor Karbon. The sole entry in the "management" category is another newcomer, Calligra Plan, a project management (i.e., Gantt charting and analysis) tool.

By any account, this adds up to a hefty application payload. The entire menagerie is available for download in a single tarball, and there are binary packages for most Linux distributions and for Windows. The project also solicits help from volunteers interested in tackling a Mac OS X build, which is a tantalizing prospect, but not one available at the moment.

The new and improved

The new text layout engine of Calligra Words gives you access to some additional document structures, such as footnotes, endnotes, tables-of-contents, and large tables that span multiple pages. The Words component is a bit different than other word processors in that it natively supports text frames — blocks that contain text, but which you can rearrange on the page just like you would an embedded image or another discrete component. This is nice if you are used to the desktop-publishing (DTP) approach (as in Scribus), because it is much easier to construct a document with multiple regions (such as columns, photo captions, or a masthead). On the other hand, a lot of people find DTP confusing for precisely this reason. Calligra Words splits the difference; like a traditional word processor it starts you off with one text frame covering the page in a new document — but unlike a word processor, the frame is not permanently attached to the page where it is.

Words and the other office components take a different approach to the user interface than other office suites. They move most of the buttons and features out of the top menu bar and place them in detachable "docks" (think floating palettes) that you can rearrange and stick together at will. I am not convinced that this results in a simpler UI as the release notes advertise — you have the same number of buttons, plus tabs to sort them, they can just be attached to the side of the document pane rather than the top. Here again, I am curious to see what the overall reaction is from users — GIMP receives constant criticism for its use of floating tool docks, after all, and the majority of modern photo editors resort to a scrolling ribbon-of-tabs-on-one-side, which quickly becomes unwieldy to search through for a particular button. But it is more friendly to the 16x10 widescreen monitor format, where horizontal space often goes to waste on portrait-orientation documents.

Among the graphics applications, Krita is the more mature. We covered the improvements to Krita 2.4 in 2011; the painting program adds several new brush engines in this release, plus a "multi-hand tool" that duplicates brush strokes, improvements to image blending modes, and a preset editor that allows you to store custom brush and tool configurations. Karbon has some catching up to do before it equals Inkscape as a vector editor — the core functionality is all there, including drawing tools, text, path, and Boolean operations. What it lacks is Inkscape's smorgasbord of fine-adjustment tools (such as alignment options and cloning tools); it is the details that separate a "professional" illustration tool from an amateur one, and you quickly get used to having them. So too with extensions; I feel like Karbon is heading in a good direction — it just needs time to flesh out the nooks and crannies.

Braindump is the most unusual of the new applications. It is a mind-mapper at heart, a blend between the diagram-generating functions of Flow and a standard note-taking application. What that means is that you can create simple text notes, and visually link them to other notes — or to images, charts, or other objects — on a whiteboard. I cannot envision Braindump being a frequently-used tool, at least at the moment, largely because it remains single-user. Certainly getting "the content of your brain" (as creator Cyrille Berger put it) out into a file is helpful when trying to get organized, but it seems far more useful when applied to a group.

Calligra Flow is a diagram creator, which makes it a bit like a stripped-down vector editor — the principle operations are placing and connecting pre-defined markers and shapes. I have run into a few incidents (such as architecture diagrams) when a good diagram editor is more useful than a free-form vector editor, so I understand the value of the tool. Flow offers an impressive library of markers and connectors; you are essentially in point-and-click territory. You have only one export option, however — an Open Document drawing (.odg). Perhaps future releases will permit SVG, HTML, or even raster output too. Until then, you can always open the drawing in another application and convert it.

Calligra Plan seems like a better fit for the "office" category (I'm not clear why it is relegated to a category all of its own). It offers a straightforward introduction to project-planning functions, including scheduling, budgeting, and resource management, and various views to explore the current status of your projects. These are questions many of us assume to be the exclusive domain of pointy-haired bosses, but to be honest most collaborative projects (including software projects) could benefit from such an application, and there is scarcely any movement on this front from other desktop or office projects. Calligra Plan could develop into a key feature in future releases.

Finally, this release includes two Calligra variants designed for use on non-desktop systems. The first is Calligra Mobile, a stripped-down suite originally designed for Nokia's N900 phone. The mobile edition includes touch-friendly editors for word processor documents, spreadsheets, and presentations. Although intended for a very small form-factor, it runs on desktop systems, too. There are fewer editing operations implemented, but Calligra Mobile is quite handy for viewing documents on the road (or for making presentations without a laptop). The second new implementation is Calligra Active, an interface built with QML and targeting touch-screen devices built on top of KDE's Plasma Active platform. In this release, Calligra Active only functions as a document viewer.

Office pace

All things considered, Calligra 2.4 is an impressive debut. Part of the credit certainly belongs to the teams that have managed their application projects for years prior to the KOffice/Calligra divide, but a lot of effort has obviously gone into standardizing and packaging the applications. Despite their different maturity levels and histories, they do feel remarkably unified. I don't know that the uniformity will help a Calligra Words user dive right in with Krita and produce museum-quality work, but knowing what to expect with UI features like templates and dockable palettes certainly helps.

There are still areas in need of improvement. For example, I am not clear why some of the applications officially have "Calligra" prepended to their names, but others do not — there is not, for instance, a clear divide on that point between the old and new or the office and non-office components. More importantly, Calligra Words has a way to go before it can challenge LibreOffice Writer as an ODF word processor. Perhaps the best thing about Calligra 2.4, though, is that it broadens the definition of an "application suite" — the division between creative and "office" applications (to take one example) is something we inherited from proprietary software companies that chose to invest in one or the other, but it is artificial. Free software can do better, and Calligra proves that integrating a more holistic set of programs can still produce a quality suite of tools.

Comments (3 posted)

Quotes of the week

-- Matt Mackall

-- Allan Day

-- Roland McGrath

Comments (1 posted)

Apache Cassandra v1.1 released

The Apache Software Foundation has announced the release of version v1.1 of the Cassandra "NoSQL" database. "Apache Cassandra v1.1 features improved caching, revised query language (CQL –Cassandra Query Language– a subset of SQL), storage control, schema/structure, Hadoop integration/output, data directory control, and scalability."

Comments (none posted)

dwz-0.1 - DWARF compression tool

dwz is a new tool for the compression of DWARF debugging data. "The tool parses DWARF2+ debug info, finds matching DIEs between different CUs that might be moved to new CUs with DW_TAG_partial_unit, estimates whether it is worthwhile, if it is, moves it there and adds DW_TAG_imported_unit DIEs (a tree of them) to make sure every CU includes all the needed DIEs." In other words, it makes executables with debug information smaller. Work to add support for the compressed format to GDB is currently underway.

Full Story (comments: none)

gitolite v3.0 released

Version 3.0 of the gitolite git hosting system has been released. It is a complete rewrite of the system adding quite a few new features and a more maintainable code base.

Full Story (comments: none)

OpenSSH 6.0 released

OpenSSH 6.0 is out. It is billed mostly as a bug-fix release, but it also includes a number of small enhancements, including the ability to cancel remote and local port forwards via the multiplex socket.

Full Story (comments: none)

Lotus Symphony for Apache OpenOffice coming

In July 2011, IBM announced that it would contribute the code for its Lotus Symphony product to the Apache OpenOffice.org project. Things have been quiet since then, but it has now been announced that this contribution will arrive just after the 3.4 release, which may happen by the end of April. It will be interesting to watch. "The source tree is comparable in size to OpenOffice, so it will not be possible for us to just check it in without interfering with Apache SVN mirroring." Stay tuned.

Full Story (comments: none)

Development newsletters from the last week

• Caml Weekly News (April 24)
• What's cooking in git.git (April 23)
• Perl Weekly (April 23)
• PostgreSQL Weekly News (April 22)
• Ruby Weekly (April 19)
• Tahoe-LAFS Weekly News (April 21)

Comments (none posted)

LV2 1.0 released, what’s next? (Libre Graphics World)

Here's an article in Libre Graphics World on the LV2 audio plugin mechanism (which just had its 1.0 release) and where things are going from here. "I am, on one hand, amazed when I see time stamps on LV2 stuff from over 5 years again. It doesn't seem like we've come very far for that long. On the other hand, when I first got in to audio development, all we had was LADSPA. Now, I have a plug-in interface with which (for example) I can build a modular synth that uses exclusively standard plug-ins to process any kind of data, and the modular synth itself can be one of those plug-ins, where the UI communicates with the engine entirely through the plug-in API which is network transparent."

Comments (5 posted)

Linus Torvalds is a finalist for the Millennium Technology Prize

Technology Academy Finland has announced that Linus Torvalds is one of two finalists for the Millennium Technology Prize. "Technology Academy Finland has today declared two prominent innovators, Linus Torvalds and Dr Shinya Yamanaka, laureates of the 2012 Millennium Technology Prize, the prominent award for technological innovation. The laureates, who will follow in the footsteps of past victors such as World Wide Web creator Sir Tim Berners-Lee, will be celebrated at a ceremony in Helsinki, Finland, on Wednesday 13 June 2012, when the winner of the Grand Prize will be announced. The prize pool exceeds EUR 1 Million." The Linux Foundation has also put out a press release about the prize.

Comments (19 posted)

Linux Audio Conference 2012 proceedings and videos available

The 2012 Linux Audio Conference was held April 12-15 at Stanford University; the proceedings of the conference and videos of the talks are now available for those who would like to learn about what was discussed or simply hear the concerts. By all appearances, it was a highly interesting event.

Comments (none posted)

LPI: Linux Essentials beta - Call for Volunteers

Linux Professional Institute (LPI) is looking for volunteers to try out a new exam in their curriculum, "Linux Essentials". "“Linux Essentials” is an innovative new program measuring foundational knowledge in Linux and Open Source Software and will be publicly released in June 2012. "Beta" exams are offered free to volunteers who wish to assist LPI in its exam development process for the "Linux Essentials" program."

LPI has also announced revisions in its LPIC-1 and LPIC-2 certification exams.

Full Story (comments: none)

FSFE: Fellowship interview with Bernd Wurst

The Fellowship of the Free Software Foundation Europe has an interview with Bernd Wurst about his involvement with Free Software. "I don’t see myself as a coder. My web hosting company schokokeks.org – founded together with Hanno Boeck – relies on Free Software, so we certainly do bug reporting and stuff. Really I’m an administrator, so in terms of Free Software, I’m only a user. But I am a proud member of OpenStreetMap, having mapped my hometown. I am a member of the FSFE Education Team, and I’m involved in the freedroidz project."

Comments (none posted)

An Alternative Reading of the IADB Study on Peru's OLPC Implementation (OLPC News)

OLPC News is carrying a response from Oscar Becerra (former Chief Educational Technologies Officer in the Peruvian Ministry of Education) to the Economist article that was rather critical of the Peruvian OLPC (or Una Laptop por Niño) project. We linked to the article and the report it was based on in early April. "It was never the program's primary goal to improve Math and Language test scores. What we expected was that the children's lives would be improved by giving them more options for their future -- something the study has proven because the children are more proficient in the use of 21st century tools (Table 5 of the study shows a dramatic increase in both access and use of computers by the treatment group) and have better cognitive skills (Table 7). It remains to be seen if with appropriate adjustments in strategy those improved cognitive skills will translate into better test scores. I don't agree with the Economist's biased reading of the study."

Comments (none posted)

Android Cookbook--New from O'Reilly Media

O'Reilly Media has released "Android Cookbook" by Ian Darwin.

Full Story (comments: none)

FreeBSD Device Drivers--New from No Starch Press

No Starch Press has released "FreeBSD Device Drivers" by Joseph Kong.

Full Story (comments: none)

Using Drupal, 2nd Edition--New from O'Reilly Media

O'Reilly Media has released "Using Drupal, 2nd Edition" by Angela Byron, Addison Berry and Bruno De Bondt.

Full Story (comments: none)

LoMus 2012

LoMus 2012 "invites music and audio open-source software creators to submit original projects that either directly or indirectly contribute to musical creation. A prize will be awarded to open-source [software] that proves to be not only innovatory but also inventive in the present context of music and audio creation." The submission deadline has been extended to April 29. The awards ceremony will take place May 11.

Full Story (comments: none)

"CloudOpen" from the Linux Foundation

The newest event hosted by the Linux Foundation is CloudOpen, to be run in parallel with LinuxCon in San Diego, California at the end of August. "CloudOpen will feature technical content that includes, but is not limited to Chef, Gluster, Hadoop, KVM, Linux, oVirt, Puppet, and Xen, as well as big data strategies and open cloud platforms and tools. This conference will also cover open source best practices and how they relate to topics such as company data and APIs." The call for proposals is open until June 1.

Comments (2 posted)

Texas Linux Fest 2012

Texas Linux Fest will take place August 3-4 in San Antonio, Texas. "In its third year, Texas Linux Fest 2012 brings the latest developments in Free/Open Source Software (FOSS) to the public, and provides a wide variety of sessions to accommodate everyone from the newest beginner to the most seasoned developer." The call for papers will be open until June 1, 2012.

Full Story (comments: none)

Wendy Seltzer to Keynote Ohio LinuxFest 2012

Ohio LinuxFest will take place September 28-30 in Columbus, Ohio. Wendy Seltzer will give a keynote address on copyright, trademark, patent, open source, privacy, and the public interest online. "Wendy Seltzer is Policy Counsel to the World Wide Web Consortium (W3C) and a Fellow with Yale Law School's Information Society Project, researching openness in intellectual property, innovation, privacy, and free expression online. As a Fellow with Harvard's Berkman Center for Internet & Society, Wendy founded and leads the Chilling Effects Clearinghouse, helping Internet users to understand their rights in response to cease-and-desist threats. She serves on the Board of Directors of The Tor Project, promoting privacy and anonymity research, education, and technology; and the World Wide Web Foundation, U.S., dedicated to advancing the web and empowering people by improving Web science, standards, and generative accessibility of Web. She seeks to improve technology policy in support of user-driven innovation and communication."

Full Story (comments: none)

Events: April 26, 2012 to June 25, 2012

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

Date(s)	Event	Location
April 25 April 28	Evergreen International Conference 2012	Indianapolis, Indiana
April 27 April 29	Penguicon	Dearborn, MI, USA
April 28	Linuxdays Graz 2012	Graz, Austria
April 28 April 29	LinuxFest Northwest 2012	Bellingham, WA, USA
May 2 May 5	Libre Graphics Meeting 2012	Vienna, Austria
May 3 May 5	Utah Open Source Conference	Orem, Utah, USA
May 7 May 11	Ubuntu Developer Summit - Q	Oakland, CA, USA
May 7 May 9	Tizen Developer Conference	San Francisco, CA , USA
May 8 May 11	samba eXPerience 2012	Göttingen, Germany
May 11 May 13	Debian BSP in York	York, UK
May 11 May 12	Professional IT Community Conference 2012	New Brunswick, NJ, USA
May 13 May 18	C++ Now!	Aspen, CO, USA
May 17 May 18	PostgreSQL Conference for Users and Developers	Ottawa, Canada
May 22 May 24	Military Open Source Software - Atlantic Coast	Charleston, SC, USA
May 23 May 26	LinuxTag	Berlin, Germany
May 23 May 25	Croatian Linux Users' Convention	Zagreb, Croatia
May 25 May 26	Flossie 2012	London, UK
May 28 June 1	Linaro Connect Q2.12	Gold Coast, Hong Kong
May 29 May 30	International conference NoSQL matters 2012	Cologne, Germany
June 1 June 3	Wikipedia & MediaWiki hackathon & workshops	Berlin, Germany
June 6 June 8	LinuxCon Japan	Yokohama, Japan
June 6 June 10	Taiwan Mini DebConf 2012	Hualien, Taiwan
June 7 June 10	Linux Vacation / Eastern Europe 2012	Grodno, Belarus
June 8 June 10	SouthEast LinuxFest	Charlotte, NC, USA
June 9 June 10	GNOME.Asia	Hong Kong, China
June 11 June 16	Programming Language Design and Implementation	Beijing, China
June 11 June 15	YAPC North America	Madison, Wisconsin, USA
June 12	UCMS '12: 2012 USENIX Configuration Management Workshop: Virtualization, the Cloud, and Scale	Boston, USA
June 12	WiAC '12: 2012 USENIX Women in Advanced Computing Summit	Boston, USA
June 12	USENIX Cyberlaw '12: 2012 USENIX Workshop on Hot Topics in Cyberlaw	Boston, USA
June 12 June 13	HotCloud '12: 4th USENIX Workshop on Hot Topics in Cloud Computing	Boston, USA
June 13 June 15	2012 USENIX Annual Technical Conference	Boston, MA, USA
June 13	WebApps '12: 3rd USENIX Conference on Web Application Development	Boston, USA
June 13 June 14	HotStorage '12: 4th USENIX Workshop on Hot Topics in Storage and File Systems	Boston, MA, USA
June 14 June 17	FUDCon LATAM 2012 Margarita	Margarita, Venezuela
June 14 June 15	TaPP '12: 4th USENIX Workshop on the Theory and Practice of Provenance	Boston, MA, USA
June 15	NSDR '12: 6th USENIX/ACM Workshop on Networked Systems for Developing Regions	Boston, MA, USA
June 15 June 16	Nordic Ruby	Stockholm, Sweden
June 15 June 16	Devaamo summit	Tampere, Finland
June 16	Debrpm Linux Packaging Workshop in the Netherlands	The Hague, Netherlands
June 19 June 21	Solutions Linux Open Source	Paris, France
June 20 June 21	Open Source Summit (NASA, State Dept, VA)	College Park, MD, USA

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