User: Password:
Subscribe / Log in / New account Weekly Edition for December 19, 2013

A 2013 retrospective

By Jonathan Corbet
December 18, 2013
Welcome to the final Weekly Edition for 2013. It has been yet another busy year in the Linux and free software community — a fact that will be surprising to few. One of the biggest problems with year-end is the fact that your editor was foolish enough to make a set of predictions at the beginning of the year; the accuracy of those predictions can now be evaluated. The result is often less than flattering, but there can be something to learn from the process.

January's mistakes

Our 2013 predictions started off with an assertion that "the full messiness of the secure boot situation" would come to the fore. In some sense that can be said to have occurred; see the ongoing discussion over the hazards of the kexec() system call, for example. Secure boot has sparked an ongoing debate over what powers the root account should really have. But it also has not turned out, so far, to be anywhere near as messy as some had feared. For the most part, systems with secure boot Just Work, and, when they Just Don't Work, the ability to turn it off is always there.

Also, notably, Microsoft has made no hostile moves toward blocking Linux from booting on machines with secure boot enabled. The threat is always there, though, and it drives the discussion on what functionality can be allowed on secure-boot-enabled systems. It remains true that Linux is subject to the good will of a competing company in this regard, and it may yet come back to haunt us.

Regarding the prediction that maintaining access to our hardware will continue to be a problem: it will not be surprising that such a safe prediction was borne out. Locked-down hardware and hardware requiring proprietary drivers to function continues to exist. On the other hand, there were some good developments if one looks closely. Motorola's decision to continue a handset's warranty after it has been unlocked is one small example, as NVIDIA's first cautious steps to provide documentation to the Nouveau project and Google's open-source firmware work. There are still a lot of problems in this area, but recognition of those problems is widespread.

An even safer prediction was the one that software patent issues would continue to be a problem. Someday, maybe, that problem will be fixed, but that day did not come in 2013.

Your editor predicted that the 3.12 kernel would be released on November 20. Predicting software releases can be hazardous, and your editor will confess that he completely blew it this time around: the 3.12 release happened on November 3, more than two weeks earlier than predicted. Last January's prediction failed to account for one of the more significant changes in the kernel development process: despite the increasing number of changes going into each release, the time required to get through the mainline development cycle is steadily shrinking. A kernel released in 2011 required 74 days to prepare. 2012's releases required 69 days, while, in 2013, that time dropped to 66 days. It will be interesting to see how much farther this trend can go.

The community, your editor predicted, would become increasingly intolerant of unpleasant behavior from its members. The "donglegate" episode in March and the kernel mailing list blowup in July would appear to bear that prediction out. But there is an undercurrent in these discussions that is worth noting: a significant percentage of our community appears to have come to believe that public confrontations and "name and shame" actions can, themselves, make our environment more hostile. There will continue to be pressure for better behavior in the future, but, perhaps, it will take a more subtle form.

Your editor suggested that it may be time for a change of management at the Free Software Foundation and the GNU Project. Regardless of whether it was actually time, no such change occurred or was even discussed.

January's predictions included one to the effect that talk of "vertical integration" would be heard often. In truth, the discussion has abated a bit, but the work in that direction continues at full speed. In many corners of our community it's an article of faith that our scattered approach to development has impeded the success of the Linux platform. Thus far, none of the attempts to create a more integrated platform have come close to rivaling Android, but that could certainly change in the future.

"Some distribution will ship a release based on Wayland," we predicted. Your editor is guessing that RebeccaBlackOS may not be accepted by all readers as a fulfillment of that particular prediction. Major changes to our systems can take a long time to reach users; Wayland is just one more example of a project that has had a lot of maturing to do before it becomes ready for widespread use. The prediction that several new Linux-based platforms would ship was similar; FirefoxOS is, indeed, commercially available, but Sailfish OS and Tizen are just getting off the ground and Ubuntu Touch is even further behind. We will see some interesting Linux-based platforms out there, but we'll have to be patient.

Predictions not made

So, as usual, some predictions were hits, and others were not. But it is just as important to ask: what was missed altogether? One thing your editor didn't see coming was Canonical's decision to pass up Wayland and write its own display server. This move stirred up the community which, for the most part, would have rather seen Canonical put its resources into making Wayland better. Whether going its own direction here (as with many other things) will pay off for Canonical remains to be seen.

In retrospect, something like the Snowden leaks had to happen at some point, but it would have been hard to foresee the actuality in 2013. Those leaks have had a significant effect on our community, making it clear that we are under attack, but also that we arguably have the best defense available against institutionalized surveillance. We have always known that closed-source software can act contrary to its users' interests; now the wider world is learning that lesson as well. Free software, in the end, may have an important role to play in maintaining the freedom of our societies.

Something that perhaps should have been foreseen was the funding of the CyanogenMod developers and the formation of Cyanogen Inc. By the time a software project builds up a few million users, somebody with money is bound to be interested in making a company out of it. So far, the funding of CyanogenMod appears to have resulted in quicker releases and the prospect of a handset or two sold with CyanogenMod preinstalled. At some point, though, some sort of revenue model will have to be developed; one hopes that can be done without alienating the CyanogenMod user base.

Finally, none of these could have been predicted, but let us remember one more time the members of our community who we lost this year: Atul Chitnis, Ray Dassen, Jan Schubert, Aaron Swartz, Malcolm Tredinnick, Seth Vidal, and others who certainly deserve mention here. We miss you all.

Other stuff

It was a busy year here at LWN. We put out 51 Weekly Editions, on schedule, containing 459 internally-written feature articles and 56 articles by outside authors. Those editions also included over 4700 security updates, 800 vulnerabilities, and 2000 kernel patches. According to our conference index (added this year), we had coverage from no less than 36 events in 2013; that probably explains why we get a lot of spam from airlines. We have tried to expand our coverage range while maintaining the strength of our core coverage with, we hope, some success. We feel good about what we were able to produce this year.

On the other hand, our in-house writing capability suffered with the departure of Michael Kerrisk in April. While we are not currently actively looking, we remain interested in talking with good writers, especially anybody with an interest in writing on kernel topics.

Individual subscriber numbers remained essentially flat in 2013, as they did in 2012, while the number of group subscriptions grew slightly. Subscriptions remain LWN's life blood; advertising only generates enough money to make us keep it around despite its many frustrations. It would thus be nice to see a return to growth in subscriptions. For those looking for a late gift idea, gift certificates are affordable and require no shipping time. Readers who use Linux at work may want to consider getting their employer to buy a group subscription for them; these groups have become an increasingly important part of our subscriber mix.

But above everything else we would like to express our deepest thanks to our reader community which has kept us going through our sixteenth year. Your interest and support are what keeps LWN operating after all these years; it is hard to imagine a better community to write for. Best holiday and new-year wishes to all of you from the LWN staff; we'll be back to do it all again in January.

Comments (6 posted)

SteamOS beta "Alchemist" arrives

By Nathan Willis
December 18, 2013

Game publisher Valve Software released the first installation images of its Linux-based SteamOS late on Friday the 13th of December. Valve had announced the SteamOS project at LinuxCon North America in September, calling it the best way to push video game development forward as Windows and proprietary game consoles become increasingly difficult to develop for. Since that announcement, the Linux community has been eager to take a peek at the first release—as has the gaming community, albeit for different reasons. Now that the first beta of SteamOS has hit the street, it is undergoing scrutiny from both angles. While gamers presumably have a lot to gain from a leaner and more customizable operating system, SteamOS's impact on Linux as a whole may be harder to pin down.

The SteamOS beta (dubbed "Alchemist") was announced on the Steam Universe discussion forum on December 13. Officially speaking, installing SteamOS on one's own hardware is regarded as "building your own Steam Machine," since Valve's primary target for the project is developing an OS for Steam Machines: living-room consoles built out of commodity PC hardware. Two downloads are available; one is a cloned disk image designed to be written directly to a hard drive, while the other is a more traditional installer meant for a USB thumb drive.

Welcome to the steam room

The installer route requires several steps, including logging in with one of the pre-defined user accounts and setting up the Steam client software, then logging in again with a different account and running a post-installation script. Despite that manual process, the installer is configured to automatically repartition the computer's first hard drive and install SteamOS over it, so testing the release does require dedicating some hardware for the task (primarily meaning a dedicated hard disk, although it should also be noted that multiple monitors and other hardware configurations have been found to prevent SteamOS from running). Valve also imposes some hard requirements on the machine itself (such as requiring UEFI boot), in addition to some softer demands on component selection. For instance, the release FAQ says that only NVIDIA graphics cards are supported, but early investigators discovered that drivers are included for AMD and Intel GPUs as well.

A workaround is required to get the installer to boot on a non-UEFI system, but it is possible. Shortly after the release announcement, volunteers at Reddit began dissecting the installer to modify it for use on older BIOS machines.

Out of the box, SteamOS offers two login sessions: one devoted solely to running the Steam client software, and one that presents a largely unmodified Linux desktop environment. Lest there be any confusion, the Steam client software is not open source, and it requires agreeing to a EULA and setting up a Steam account in order to get started. SteamOS also includes binary video drivers for the target graphics cards.

The basic operating system itself, however, is a bare-bones Debian 7.1 with a set of patches applied to hone gaming performance. Valve has an Apt repository running at where one can scrutinize the included packages. The major changes are an updated and patched 3.10 kernel (Debian uses 3.2), an eglibc 2.17 (backported from Debian sid; Debian 7.1 includes 2.13), and a custom display compositor.

The compositor attracted considerable attention in discussion forums at release time, with plenty of Linux users evidently eager to hear whether SteamOS would "take sides" in the race between Wayland and Mir. Both camps were no doubt let down that Valve went with neither option. Instead, steamos-compositor is adapted from the venerable xcompmgr, a lightweight compositor much older than Wayland and Mir. Perhaps that should be no surprise; as the release FAQ put it, the compositor is designed to provide nice transitions between the Steam client and games—which, presumably, will run full screen OpenGL. Those keeping score on intra-community competition will also want to note that SteamOS uses sysvinit, rather than systemd or Upstart (although, to be frank, it is hard to imagine anyone who had a strong opinion about any of these debates being particularly swayed by Valve's choices for SteamOS).

The choices for the kernel and graphics drivers are probably of more general interest. The kernel package [tar.xz] includes, among others, a large number of realtime patches and a patch set for the aufs union filesystem. Ostensibly, the issue that Valve cares most about is improving game performance (and indeed Valve is reported to have worked on improvements to the binary NVIDIA drivers included with SteamOS). Over at Phoronix, Michael Larabel posted a set of benchmarks running the NVIDIA binary drivers on the SteamOS kernel, a vanilla 3.10 kernel, and the most recent Ubuntu kernel. Larabel's level of detail is thorough as always, but his results show the SteamOS kernel to provide the lowest framerate performance of the bunch (although he also notes that the beta testing itself is probably what will lead to improvements).

Then again, there are plenty of other factors that go into gaming performance. Framerate is generally viewed as a simple metric for apples-to-apples comparisons—all else being equal, if altering one component on the system can draw frames to the screen faster, then it should be able to do everything else faster. What Valve expects from the realtime patches is unclear; realtime offers deterministic performance but rarely if ever does it offer faster performance. There are certainly metrics that the kernel could be optimized for, but it would be more informative to hear from Valve about their choices. Things like delivering reliable network performance, in order to reduce perceived lag between the game client and the remote server, are usually high on gamer's lists after framerate, as is responsiveness to input. Aufs is probably used for simple backup and restoration (which is important for any "appliance" computer); the SteamOS installer creates a recovery image as soon as it has finished pulling in package updates on first run.

Reading the steam leaves

On the gaming front, sadly, I must confess that I am simply not a gamer at heart—and thus not qualified to dispense advice on game performance where SteamOS or anything else is concerned. I installed the SteamOS beta on a machine that primarily serves as a home theater PC (HTPC). Thus the box is connected to a flatscreen TV, and is about ten feet from seating (which is the canonical distance for this sort of user experience). But the hardware in question sports an aging-by-today's-standards fanless video card whose specs would probably make most dedicated gamers weep with sorrow. It is an NVIDIA card, though, so SteamOS's "BigPicture" interface will run on it without any tweaking.

The experience is certainly smooth, and it is easier to get started with than many other distributions. On the other hand, the desktop session is a bit of a puzzle in light of SteamOS's stated purpose. Users can launch a run-of-the-mill GNOME 3 or GNOME Classic session, but there is not much software available from Valve's SteamOS repositories. Other than Iceweasel and development tools, it is a bare-bones environment. One can add the Debian repositories, of course, and apart from conflicting kernel and eglibc packages set up more or less a standard desktop Linux system. The SteamOS FAQ notes that Valve may expand the package set its repository provides, but says little else. Thus it is hard to escape the feeling that Valve is not terribly interested in what people do with the SteamOS "desktop" experience. There is no guidance for users, and the Steam site still recommends that users interested in running Linux go download Ubuntu.

The company is open about its intention for Steam Machines to supplant console video game systems; as such, it may not care at all what else users do with their hardware. Linux is still an officially supported platform for the Steam client, but more of Valve's marketing muscle about consumer desktops is focused on Steam's ability to stream game content live from one machine (say a Steam Machine) to another (for example, a Windows box).

That may mean that only a few SteamOS users will ultimately be drawn into desktop Linux usage. Of course, the size of the PC gaming market is so enormous that even a tiny percentage of its users could constitute a massive influx. The company's current statistics show around 6.3 million concurrent users at the daily peak. But so far there is no indication that Valve has any interest in becoming a "normal" Linux distribution. So any additional users are most likely to end up either in Debian directly or perhaps with a derivative like Ubuntu.

From a distribution development standpoint, though, SteamOS could provide considerable benefits to the rest of the Linux community: a slice of those 6.3 million concurrent users would no doubt push improvements to video drivers to start with (hopefully both binary and open source, as gamers are wont to try everything in search of additional performance). Getting games running on SteamOS is likely to impact OpenGL game development and debugging tools, and result in more work on compositing performance (again, mostly through Valve's compositor, but others would likely be put to the test, too). Furthermore, the last big element in Valve's SteamOS push is the next-generation "Steam Controller" (which is currently only available to designated beta testers). The good news there, however, is that the controller presents itself as a standard USB HID-class peripheral, which means it should work out of the box on Linux systems.

It is also worth noting that, whatever Valve's plans involve for the desktop, at the moment the SteamOS release is available through the Apt repository alone. While it would be nice for the company to work upstream and host source in public version control, they are not doing so at the moment. Certainly they are not obligated to do so, but one would hope that it is a step still to come. Valve does host a public issue tracker for SteamOS on GitHub, so there is reason to be hopeful.

SteamOS may yet evolve to become a major factor in desktop Linux development, or it may remain an appliance-like specialty distribution focused on its own core mission. In either case, the rest of the Linux community has something to learn by watching its progress—millions of prospective users are nothing to sneeze at. Perhaps the best advice other distributions could heed in the wake of the first SteamOS release is that they should get ready, watch how Valve's kernel tweaks impact performance, and listen to what all of those new-to-Linux users have to say about their first foray into the Linux desktop.

Comments (43 posted)

2013 Linux and free software timeline - Q4

By Nathan Willis
December 19, 2013

Here is LWN's sixteenth annual timeline of significant events in the Linux and free software world for the year. As per tradition, we divide up the timeline up into quarters; this is our account of October–December 2013. Timelines are also available covering was January through March, April through June and July through September; the combined timeline for all of 2013 will appear after the start of the new year, including any late-breaking stories.

There are almost certainly some errors or omissions; if you find any, please send them to

LWN subscribers have paid for the development of this timeline, along with previous timelines and the weekly editions. If you like what you see here, or elsewhere on the site, please consider subscribing to LWN.

For those readers in a retro mood, our timeline index page includes links to the previous timelines and other retrospective articles that date all the way back to 1998.


FreeBSD 9.2 is released (announcement). PC-BSD 9.2 is released shortly afterward (announcement).

However, the real problem with biometric security lies with its inability to replace a compromised authentication device. Once someone has a copy of your ten fingerprints, a drop of your blood from a stolen blood-sugar test, or a close-up video of your eye from a scoped video camera, there is no way to change this data. You can't ask helpdesk to send you new fingers, an eyeball, or DNA.

-- Stephen Gallagher

Mozilla merges Shumway, its open source JavaScript interpreter for Flash files, into Firefox (LWN article).

A great many projects wrap up their involvement in the 2013 Google Summer of Code and reflect on the summer's experience, including Debian and openSUSE.

GNU Make 4.0 is released (announcement).

The AtypI Conference is held in Amsterdam, October 9 to 13 (LWN coverage).

Similarly, some open source coming out of universities and companies simply isn't open source enough as there is a fair amount of side dealing going around on around patents. I'm tempted to say that if it isn't a patent granting license, you should be suspicious, but that's probably a bit extreme a position to take at this time.

-- Chris DiBona

[Wayland logo]

Wayland / Weston 1.3 is released (announcement).

Version 2.0 of the Cinnamon desktop environment is released (announcement).

XBMC DevCon 2013 is held in Munich, October 11 to 13 (report).

LinuxCon Europe is held in Edinburgh, October 21 to 23 (LWN coverage).

Crypto without a threat model is like cookies without milk. You're making a claim about the security of a cryptographic algorithm without specifying the threat model. You are, technically, in a state of sin. I forgive you my son. Your penance is to memorize another 30 digits of pi.

-- Russ Nelson

GStreamer Conference 2013 is held in Edinburgh , October 22 to 23 (LWN coverage).

The 2013 Kernel Summit is held in Edinburgh, October 23 to 25 (LWN coverage).

Ubuntu 13.10 is released (announcement). The new distribution release coincides with the release of Ubuntu Touch 1.0 for mobile devices (LWN article).

The Yocto project releases version 1.5 (announcement).

[OSI logo]

The Open Source Initiative appoints Patrick Masson as General Manager (announcement).

You are surely aware that by general consensus the responsibility for a generic implementation falls to the third person to reimplement it from scratch, which in this case wasn't me for a change...

-- Thierry Reding

Embedded Linux Conference Europe is held in Edinburgh, October 24 to 25 (LWN coverage).

The Fall Automotive Linux Summit is held in Edinburgh, October 24 to 25 (LWN coverage).

The Linux Foundation elects its Technical Advisory Board for the coming year (announcement).

Fedora creates working groups to guide the distribution's development in four specific directions: workstation, server, cloud, and base design (announcement; LWN article).

Of course, you can certainly refuse to sign such a CLA not because of its content but because you don't like the company behind it. For example if you are convinced Canonical is using contributions to build a machine to eradicate all the kittens on Earth, do not sign the CLA! Think about the kittens!

-- Aurélien Gâteau

Cisco announces the release of a BSD-licensed H.264 video decoder and promises to absorb all of the MPEG-LA licensing costs associated with its use downstream (announcement). Mozilla announces that it will include the decoder in Firefox.

The first Tizen-powered tablet goes on sale in Japan (report).

The Realtime Linux Workshop is held in Lugano, October 28 to 31 (LWN article). Realtime patchset maintainer Thomas Gleixner expresses concern for the future of the project.

[DarkMail logo]

Former Lavabit and Silence Circle founders announce the Dark Mail Alliance, whose mission (in the wake of the Snowden disclosures and subsequent government investigations) is to bring end-to-end email encryption to the masses (LWN article).


Kernel 3.12 is released (announcement; merge window 1, 2, 3; development statistics; KernelNewbies page).

I wonder if it should be called kernel/locks, as that's less to type, smaller path names, and tastes good on bagels.

-- Steven Rostedt

OpenBSD 5.4 is released (announcement).

Debian debates whether and how to select an init–replacement system, a technical choice on which the distribution has previously remained silent (LWN article).

SystemTap 2.4 is released (announcement).

[Blender logo]

Blender 2.69 is released (announcement).

PyDev 3.0 is released (announcement).

[XOrg logo]

Version 1.0 of the DRI3 and Present protocol extensions for X are released (announcements; LWN article).

Django 1.6 is released (announcement).

Just for the record. I'm really frightened by the phrase "UDP realtime" which was mentioned in this thread more than once. Looking at the desperation level of these posts I fear that there are going to be real world products out already or available in the near future which are based on the profound lack of understanding of the technology they are based on.

This just confirms my theory that most parts of this industry just work by chance.

-- Thomas Gleixner

Apple and Microsoft sue Google and a number of Android handset manufacturers for infringing on the Nortel patents the plaintiffs purchased in 2011. (Ars technica report; LWN article).

Valgrind 3.9.0 is released (announcement).

The Korea Linux Forum is held in Seoul, November 13 to 14 (LWN coverage).

[Dart logo]

Dart SDK 1.0 is released (announcement).

The Go language celebrates four years (announcement).

openSUSE 13.1 is released (announcement).

[CC logo]

Creative Commons releases version 4.0 of its licenses for artistic and creative works (LWN article).

Checkpoint/restore tool 1.0 is released (announcement).

The Jailhouse hypervisor is announced (announcement).

I think LibreOffice is a pretty good model for WYSIWYG, apart from not being Emacs.

-- Richard Stallman

OpenMandriva Lx 2013.0 is released, the first stable release from the OpenMandriva Association (announcement).


We never build a Toyota Corolla, we're perpetually building motor show prototypes - something with all sorts of shiny amazing features that isn't really intended to work satisfactorily in the real world. We're not interested in doing the last 20% of boring work to turn our super-exciting prototype into something Joe Normal will drive to work every day: we just want to keep building more super-exciting prototypes.


*but*, I'm not saying that's actually what we should do. I quite like building exciting prototypes. Building Corollas probably ain't as much fun.

-- Adam Williamson

CyanogenMod 10.2.0 is released, marking the last CM release to be based on the Android 4.3 code (announcement).

Keith Packard joins the Debian Technical Committee (announcement).

Version 39.0 of the Emacspeak audio desktop is released (announcement).

GCC gains a front-end for the Rust language (announcement).

[EFL logo]

EFL 1.8 is released (announcement).

CyanogenMod begins integrating end-to-end encrypted messaging via WhisperPush (LWN article).

Mozilla releases the first nightly builds of multi-process Firefox (announcement; LWN article).

[KDevelop logo]

KDevelop 4.6.0 is released (announcement).

Firefox 26 is released. Among other changes, this release implements H.264 decoding on Linux via a GStreamer plug-in (announcement).

If Documentation/memory-barriers.txt could not be used to frighten small children before, it certainly can now.

-- Mel Gorman

FreeBSD decides that it no longer regards crypto chips from Intel and Via as trustworthy, in light of allegations about secret US government efforts to weaken cryptographic algorithms (Ars technica report).

[AllSeen logo]

The Linux Foundation announces the AllSeen Alliance to work on standards and best practices for "Internet of Things"–style projects (announcement).

Valve releases the first installable images of its Steam OS Linux distribution (announcement; LWN article).

Fedora 20 is released (announcement).

Google becomes an Open Invention Network board member (announcement).

Comments (1 posted)

Page editor: Jonathan Corbet


Known-exploit detection for the kernel

By Jake Edge
December 18, 2013

An attacker might try a number of different kernel exploits before actually getting one that works with a specific running kernel. If the kernel were instrumented to detect the failed attempts, it could alert system administrators about an in-progress attack in addition to returning an error code to the attacker. That's the idea behind a patch set proposed by Vegard Nossum: complain loudly when someone attempts to exploit a closed security hole.

Any given kernel will have both patched and unpatched vulnerabilities; hopefully the latter are far fewer than the former. When targeting a system, attackers can either figure out which kernel version is running and what vulnerabilities it is likely to have, or they can just try to exploit a bunch of recent vulnerabilities. Many attacks seem to be of this untargeted, mass-attack style, so recognizing and flagging failed attempts may help administrators put a stop to the attacks.

Nossum suggested adding an exploit() annotation to the fixes for specific kinds of now-closed security holes. For example, in sock_alloc_send_pskb() from net/core/sock.c:

    if (npages > MAX_SKB_FRAGS) {
        goto failure;

In suitably configured kernels, that would put out a rate-limited message to the system logs noting a "possible exploit attempt". But, he said, the annotations should not be for all bugs, nor should they have an unlimited lifespan:

I propose limiting the annotation of known exploits to the most serious type of exploit, namely where the attacker otherwise silently gains root/elevated capabilities. For sure, there is little point in calling exploit() where an older kernel would just panic or OOM.

I also propose to keep each exploit() annotation around for only ~5 years after the bug was discovered/fixed. This will allow us to catch most of the intrusion attempts while still not littering the kernel code forever.

The reaction has largely been positive, though there were some concerns and quibbles. Ted Ts'o wondered if malware writers would just start checking kernel versions more carefully to avoid setting off the alarms. But Kees Cook is not convinced that testing for kernel versions will be all that effective:

The reality of the situation is that the kernels running on an end-user's system is rarely a stock upstream kernel. As a result, they usually have organization-specific versioning, which makes version-only autodetection useless to an attacker. While it is possible to keep track of all distro versions in a massive table, even the public exploits rarely do this, instead focusing on maybe one or two distros. But when attacking systems with kernels built custom by various organizations that don't publish their kernel trees, it becomes impossible to rely on just the version. Given all the forks, and stable vs mainline, and backported patches vs not, the version tends to only give a gross ball-park idea. Probing is still useful to an attacker, and this proposes reporting those probes.

Ts'o disagreed, as he believes the landscape mostly consists of distribution kernels: "testing for various distribution kernel versions, as well as specific ChromeOS and Android kernel versions, wouldn't be that difficult for an attacker, and would probably allow them to avoid detection for 99% of the Linux systems found in the wild". Cook noted that careful attackers aren't really the focus of this work. He believes that there are a lot more custom kernels installed than Ts'o does, but recognizes there is no real way to know. There are "sloppy attackers", though, who will probe all kinds of kernels without doing any checks first—Nossum's patches would potentially catch some of those.

Furthermore, Ts'o is skeptical that the enterprise distributions will even build with the CONFIG_EXPLOIT_DETECTION flag turned on. The support burden for explaining false positives (and actual attacks for that matter) might be rather high. While not speaking in any official capacity, Jiri Kosina said that he suspected SUSE would indeed turn off exploit detection to try to "maintain sanity of our support engineers".

Ryan Mallon is worried that attackers will just clean out the logs as soon as they hit upon a successful attack. But Ingo Molnar pointed out that many sites do not rely on log files on the local disk, but instead use the network or append-only media to protect their logs.

The logistics of adding the annotations as well as maintaining them going forward was another area of concern. Cook volunteered to help add annotations, but wanted to make sure that he wasn't the only one doing so. Dave Jones wondered about tests to ensure the triggers are still firing correctly when code around them changes. James Morris is also concerned about the long-term maintenance of the triggers. He is not at all sure that the feature belongs in the mainline "without at least first being proven in the field".

Adding tests could also help ensure that a vulnerability doesn't get reintroduced, which is something that has happened several times in the past, as Molnar pointed out. In addition, he said, annotating earlier bugs will help alert kernel developers to "'hotspot' areas in the kernel that tend to attract more bugs than others". The annotations will also help point out dangerous patterns in the code.

Nossum has been maintaining the patch set for around six months at this point. It consists of two base patches, one that adds the exploit() call and another to hook it into the audit subsystem, and then seven patches to add annotations for CVEs from the past two years. The latter patches are largely "one-liners in the error path of a specific input validation check". He doesn't believe there is much of a maintenance burden for the triggers and plans to maintain a public git repository with the patches going forward.

Linus Torvalds was generally in favor of the idea: "I think that it's a good idea to at least have the option to complain about certain errors, and leave markers in the logs about things that look suspicious." But he doesn't want to see annotations added for random CVEs, just those that are actually being used by rootkits or other malware. Cook and Nossum both seem to be on the same page with Torvalds; that only "serious privilege escalation issues" (in Cook's words) get annotated.

While it may not catch that many attackers, catching even one is clearly better than none. Given that the patch is lightweight, and has a low maintenance burden, it wouldn't be a surprise to see it get added to the mainline before too long. As Molnar suggested, for more security-sensitive installations, exploit() could be turned into a more active deterrent that freezes all tasks being run by the suspected UID. It could certainly be a useful tool in the ever-escalating battle between administrators and attackers.

Comments (48 posted)

Brief items

Security quotes of the week

This is one of the problems of using a rare security tool. The very thing that gives you plausible deniability also makes you the most likely suspect. The FBI didn't have to break Tor; they just used conventional police mechanisms to get [Eldo] Kim to confess.

Tor didn't break; Kim did.

Bruce Schneier

Days later, I was told my government had made me stateless and wanted to imprison me. The price for my speech was my passport, but I would pay it again: I will not be the one to ignore criminality for the sake of political comfort. I would rather be without a state than without a voice.

If Brazil hears only one thing from me, let it be this: when all of us band together against injustices and in defence of privacy and basic human rights, we can defend ourselves from even the most powerful systems.

Edward Snowden in an open letter to the Brazilian people

And it's not just keyboards. It's ebook readers. Flashlights. Not your smartphone, but the removable battery in your smartphone. (Have you noticed it running down just a little bit faster?) Your toaster and your kettle are just the start. Could your electric blanket be spying on you?
Charlie Stross worries about the "internet of things"

Here, we describe a new acoustic cryptanalysis key extraction attack, applicable to GnuPG's current implementation of RSA. The attack can extract full 4096-bit RSA decryption keys from laptop computers (of various models), within an hour, using the sound generated by the computer during the decryption of some chosen ciphertexts. We experimentally demonstrate that such attacks can be carried out, using either a plain mobile phone placed next to the computer, or a more sensitive microphone placed 4 meters away.
Daniel Genkin, Adi Shamir, and Eran Tromer (GPG has released a fix.)

Comments (3 posted)

EFF: Google removes vital privacy feature from android

The Electronic Frontier Foundation has put out a release bemoaning the removal of the "AppOps" feature from the Android 4.4.2 release. "When asked for comment, Google told us that the feature had only ever been released by accident — that it was experimental, and that it could break some of the apps policed by it. We are suspicious of this explanation, and do not think that it in any way justifies removing the feature rather than improving it." AppOps allows the tweaking of individual permissions for apps; it will be interesting to see whether CyanogenMod finds a way to retain support for this feature.

Comments (16 posted)

Deslauriers: Ubuntu Touch and User Privacy

On his blog, Ubuntu kernel developer security team technical lead Marc Deslauriers looks at the app security model for Ubuntu Touch. He contrasts the Android model requiring users to choose allowed permissions at app install time to that of the "trusted helpers" used by Touch. "For example, instead of granting permission to directly access all of the user’s contact list, an application can request access to a contact. The system address book will then display a list of contacts to the user and only the specific contact selected by the user will be sent to the application. The application only has access to the contact which was specifically authorized by the user. If a flashlight application needs access to a user contact in order for a “Recommend this app to friends!” button to work, the user will be making an informed choice, as the request will be the direct result of having pressed the button. The flashlight app can be used without fear of it accessing contact information during normal usage." AppArmor is used behind the scenes to confine the apps.

Comments (51 posted)

New vulnerabilities

curl: information disclosure

Package(s):curl CVE #(s):CVE-2013-6422
Created:December 18, 2013 Updated:December 20, 2013
Description: From the Ubuntu advisory:

Marc Deslauriers discovered that libcurl incorrectly verified CN and SAN name fields when digital signature verification was disabled in the GnuTLS backend. When libcurl is being used in this uncommon way by specific applications, an attacker could exploit this to perform a man in the middle attack to view sensitive information or alter encrypted communications.

Gentoo 201401-14 curl 2014-01-20
Debian DSA-2824-1 curl 2013-12-19
Ubuntu USN-2058-1 curl 2013-12-18

Comments (none posted)

djvulibre: code execution

Package(s):djvulibre CVE #(s):CVE-2012-6535
Created:December 17, 2013 Updated:February 10, 2014
Description: From the CVE entry:

DjVuLibre before, as used in Evince, Sumatra PDF Reader, VuDroid, and other products, allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted DjVu (aka .djv) file.

Debian DSA-2844-1 djvulibre 2014-01-15
Gentoo 201402-13 djvu 2014-02-09
Ubuntu USN-2056-1 djvulibre 2013-12-16

Comments (none posted)

gnupg: side channel attack

Package(s):gnupg CVE #(s):CVE-2013-4576
Created:December 18, 2013 Updated:June 27, 2014
Description: From the Debian advisory:

Genkin, Shamir and Tromer discovered that RSA key material could be extracted by using the sound generated by the computer during the decryption of some chosen ciphertexts.

Scientific Linux SLSA-2014:0016-1 gnupg 2014-01-09
Oracle ELSA-2014-0016 gnupg 2014-01-08
CentOS CESA-2014:0016 gnupg 2014-01-08
Red Hat RHSA-2014:0016-01 gnupg 2014-01-08
Ubuntu USN-2059-1 gnupg 2013-12-18
Fedora FEDORA-2013-23615 gnupg 2013-12-30
Fedora FEDORA-2013-23678 gnupg 2013-12-30
Slackware SSA:2013-354-01 gnupg 2013-12-21
Mageia MGASA-2013-0382 gnupg 2013-12-20
Fedora FEDORA-2013-23603 gnupg 2013-12-23
Mandriva MDVSA-2013:295 gnupg 2013-12-19
Debian DSA-2821-1 gnupg 2013-12-18

Comments (none posted)

hdapsd: unspecified vulnerability

Package(s):hdapsd CVE #(s):
Created:December 16, 2013 Updated:December 23, 2013
Description: From the Fedora advisory:

New version with minor fixes and mitigating possible security issue.

Fedora FEDORA-2013-22713 hdapsd 2013-12-22
Fedora FEDORA-2013-22761 hdapsd 2013-12-15

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CVE-2013-2929 CVE-2013-2930 CVE-2013-4513 CVE-2013-4587 CVE-2013-6376 CVE-2013-6381 CVE-2013-6383
Created:December 18, 2013 Updated:May 8, 2014
Description: From the Mageia advisory:

The Linux kernel before 3.12.2 does not properly use the get_dumpable function, which allows local users to bypass intended ptrace restrictions or obtain sensitive information from IA64 scratch registers via a crafted application, related to kernel/ptrace.c and arch/ia64/include/asm/processor.h (CVE-2013-2929)

The perf_trace_event_perm function in kernel/trace/trace_event_perf.c in the Linux kernel before 3.12.2 does not properly restrict access to the perf subsystem, which allows local users to enable function tracing via a crafted application. (CVE-2013-2930)

Buffer overflow in the oz_cdev_write function in drivers/staging/ozwpan/ozcdev.c in the Linux kernel before 3.12 allows local users to cause a denial of service or possibly have unspecified other impact via a crafted write operation. (CVE-2013-4513)

Array index error in the kvm_vm_ioctl_create_vcpu function in virt/kvm/kvm_main.c in the KVM subsystem in the Linux kernel through 3.12.5 allows local users to gain privileges via a large id value (CVE-2013-4587)

The recalculate_apic_map function in arch/x86/kvm/lapic.c in the KVM subsystem in the Linux kernel through 3.12.5 allows guest OS users to cause a denial of service (host OS crash) via a crafted ICR write operation in x2apic mode. (CVE-2013-6376)

Buffer overflow in the qeth_snmp_command function in drivers/s390/net/qeth_core_main.c in the Linux kernel through 3.12.1 allows local users to cause a denial of service or possibly have unspecified other impact via an SNMP ioctl call with a length value that is incompatible with the command-buffer size. (CVE-2013-6381)

The aac_compat_ioctl function in drivers/scsi/aacraid/linit.c in the Linux kernel before 3.11.8 does not require the CAP_SYS_RAWIO capability, which allows local users to bypass intended access restrictions via a crafted ioctl call. (CVE-2013-6383)

openSUSE openSUSE-SU-2015:0566-1 kernel 2015-03-21
SUSE SUSE-SU-2015:0481-1 kernel 2015-03-11
Oracle ELSA-2015-0290 kernel 2015-03-12
Scientific Linux SLSA-2014:1971-1 kernel 2014-12-10
Oracle ELSA-2014-1971 kernel 2014-12-09
CentOS CESA-2014:1971 kernel 2014-12-10
Red Hat RHSA-2014:1971-01 kernel 2014-12-09
Oracle ELSA-2014-1392 kernel 2014-10-21
SUSE SUSE-SU-2014:0908-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0909-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0910-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0911-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0912-1 Linux kernel 2014-07-17
openSUSE openSUSE-SU-2014:0766-1 Evergreen 2014-06-06
Red Hat RHSA-2014:0634-01 kernel 2014-06-04
Scientific Linux SLSA-2014:0475-1 kernel 2014-05-08
CentOS CESA-2014:0475 kernel 2014-05-08
Oracle ELSA-2014-0475 kernel 2014-05-07
Red Hat RHSA-2014:0475-01 kernel 2014-05-07
Red Hat RHSA-2014:0476-01 kernel 2014-05-07
Debian DSA-2906-1 linux-2.6 2014-04-24
SUSE SUSE-SU-2014:0536-1 Linux kernel 2014-04-16
Scientific Linux SLSA-2014:0285-1 kernel 2014-03-13
Oracle ELSA-2014-0285 kernel 2014-03-13
Oracle ELSA-2014-0285 kernel 2014-03-13
CentOS CESA-2014:0285 kernel 2014-03-13
Red Hat RHSA-2014:0285-01 kernel 2014-03-12
Red Hat RHSA-2014:0284-01 kernel 2014-03-11
Ubuntu USN-2141-1 linux-ti-omap4 2014-03-07
Ubuntu USN-2139-1 linux-ti-omap4 2014-03-07
Ubuntu USN-2136-1 linux-lts-raring 2014-03-07
Ubuntu USN-2135-1 linux-lts-quantal 2014-03-07
Ubuntu USN-2138-1 kernel 2014-03-07
Ubuntu USN-2128-1 kernel 2014-03-05
Ubuntu USN-2129-1 EC2 kernel 2014-03-05
Ubuntu USN-2116-1 linux-ti-omap4 2014-02-18
Ubuntu USN-2115-1 linux-ti-omap4 2014-02-18
Ubuntu USN-2110-1 linux-ti-omap4 2014-02-18
Ubuntu USN-2113-1 linux-lts-saucy 2014-02-18
Ubuntu USN-2112-1 linux-lts-raring 2014-02-18
Ubuntu USN-2111-1 linux-lts-quantal 2014-02-18
Ubuntu USN-2117-1 kernel 2014-02-18
Ubuntu USN-2114-1 kernel 2014-02-18
Ubuntu USN-2109-1 kernel 2014-02-18
Ubuntu USN-2107-1 kernel 2014-02-18
Ubuntu USN-2108-1 EC2 kernel 2014-02-18
Red Hat RHSA-2014:0100-01 kernel-rt 2014-01-28
Mandriva MDVSA-2014:001 kernel 2014-01-13
Ubuntu USN-2074-1 linux-ti-omap4 2014-01-03
Ubuntu USN-2076-1 linux-ti-omap4 2014-01-03
Ubuntu USN-2072-1 linux-ti-omap4 2014-01-03
Ubuntu USN-2067-1 linux-ti-omap4 2014-01-03
Ubuntu USN-2070-1 linux-lts-saucy 2014-01-03
Ubuntu USN-2069-1 linux-lts-raring 2014-01-03
Ubuntu USN-2068-1 linux-lts-quantal 2014-01-03
Ubuntu USN-2073-1 kernel 2014-01-03
Ubuntu USN-2071-1 kernel 2014-01-03
Ubuntu USN-2075-1 kernel 2014-01-03
Ubuntu USN-2066-1 kernel 2014-01-03
CentOS CESA-2013:X018 kernel 2013-12-28
openSUSE openSUSE-SU-2014:0247-1 kernel 2014-02-18
Oracle ELSA-2014-3002 kernel 2014-02-12
Scientific Linux SLSA-2014:0159-1 kernel 2014-02-12
openSUSE openSUSE-SU-2014:0205-1 kernel 2014-02-06
Fedora FEDORA-2013-23445 kernel 2013-12-21
Fedora FEDORA-2013-23653 kernel 2013-12-21
Mandriva MDVSA-2013:291 kernel 2013-12-18
Mageia MGASA-2013-0375 kernel-vserver 2013-12-18
Mageia MGASA-2013-0373 kernel-tmb 2013-12-18
Mageia MGASA-2013-0374 kernel-rt 2013-12-18
Mageia MGASA-2013-0372 kernel-linus 2013-12-18
Mageia MGASA-2013-0371 kernel 2013-12-17
Oracle ELSA-2014-0159 kernel 2014-02-12
CentOS CESA-2014:0159 kernel 2014-02-12
CentOS CESA-2014:X004 xen 2014-02-12
CentOS CESA-2014:X005 kernel 2014-02-12
Red Hat RHSA-2014:0159-01 kernel 2014-02-11
Mageia MGASA-2014-0043 kernel-linus 2014-02-10
openSUSE openSUSE-SU-2014:0204-1 kernel 2014-02-06

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CVE-2013-4512 CVE-2013-4514 CVE-2013-4515 CVE-2013-6763
Created:December 18, 2013 Updated:December 18, 2013
Description: From the Mandriva advisory:

Buffer overflow in the exitcode_proc_write function in arch/um/kernel/exitcode.c in the Linux kernel before 3.12 allows local users to cause a denial of service or possibly have unspecified other impact by leveraging root privileges for a write operation (CVE-2013-4512).

Multiple buffer overflows in drivers/staging/wlags49_h2/wl_priv.c in the Linux kernel before 3.12 allow local users to cause a denial of service or possibly have unspecified other impact by leveraging the CAP_NET_ADMIN capability and providing a long station-name string, related to the (1) wvlan_uil_put_info and (2) wvlan_set_station_nickname functions (CVE-2013-4514).

The bcm_char_ioctl function in drivers/staging/bcm/Bcmchar.c in the Linux kernel before 3.12 does not initialize a certain data structure, which allows local users to obtain sensitive information from kernel memory via an IOCTL_BCM_GET_DEVICE_DRIVER_INFO ioctl call (CVE-2013-4515).

The uio_mmap_physical function in drivers/uio/uio.c in the Linux kernel before 3.12 does not validate the size of a memory block, which allows local users to cause a denial of service (memory corruption) or possibly gain privileges via crafted mmap operations, a different vulnerability than CVE-2013-4511 (CVE-2013-6763).

Mandriva MDVSA-2014:155 kernel 2014-08-07
openSUSE openSUSE-SU-2014:0766-1 Evergreen 2014-06-06
Debian DSA-2906-1 linux-2.6 2014-04-24
Ubuntu USN-2074-1 linux-ti-omap4 2014-01-03
Ubuntu USN-2076-1 linux-ti-omap4 2014-01-03
Ubuntu USN-2072-1 linux-ti-omap4 2014-01-03
Ubuntu USN-2067-1 linux-ti-omap4 2014-01-03
Ubuntu USN-2070-1 linux-lts-saucy 2014-01-03
Ubuntu USN-2069-1 linux-lts-raring 2014-01-03
Ubuntu USN-2068-1 linux-lts-quantal 2014-01-03
Ubuntu USN-2073-1 kernel 2014-01-03
Ubuntu USN-2071-1 kernel 2014-01-03
Ubuntu USN-2075-1 kernel 2014-01-03
Ubuntu USN-2064-1 kernel 2014-01-03
Ubuntu USN-2066-1 kernel 2014-01-03
Ubuntu USN-2065-1 EC2 kernel 2014-01-03
openSUSE openSUSE-SU-2014:0247-1 kernel 2014-02-18
Mandriva MDVSA-2013:291 kernel 2013-12-18
openSUSE openSUSE-SU-2014:0204-1 kernel 2014-02-06

Comments (none posted)

kernel: two vulnerabilities

Package(s):kernel CVE #(s):CVE-2013-6367 CVE-2013-6368
Created:December 13, 2013 Updated:February 14, 2014

From the Red Hat advisory:

A divide-by-zero flaw was found in the apic_get_tmcct() function in KVM's Local Advanced Programmable Interrupt Controller (LAPIC) implementation. A privileged guest user could use this flaw to crash the host. (CVE-2013-6367, Important)

A memory corruption flaw was discovered in the way KVM handled virtual APIC accesses that crossed a page boundary. A local, unprivileged user could use this flaw to crash the system or, potentially, escalate their privileges on the system. (CVE-2013-6368, Important)

Oracle ELSA-2014-1392 kernel 2014-10-21
Debian DSA-2906-1 linux-2.6 2014-04-24
SUSE SUSE-SU-2014:0537-1 Linux kernel 2014-04-17
Red Hat RHSA-2014:0284-01 kernel 2014-03-11
Ubuntu USN-2141-1 linux-ti-omap4 2014-03-07
Ubuntu USN-2134-1 linux-ti-omap4 2014-03-07
Ubuntu USN-2139-1 linux-ti-omap4 2014-03-07
Ubuntu USN-2136-1 linux-lts-raring 2014-03-07
Ubuntu USN-2135-1 linux-lts-quantal 2014-03-07
Ubuntu USN-2138-1 kernel 2014-03-07
Ubuntu USN-2133-1 kernel 2014-03-07
Ubuntu USN-2128-1 kernel 2014-03-05
Ubuntu USN-2129-1 EC2 kernel 2014-03-05
Ubuntu USN-2110-1 linux-ti-omap4 2014-02-18
Ubuntu USN-2113-1 linux-lts-saucy 2014-02-18
Ubuntu USN-2117-1 kernel 2014-02-18
Ubuntu USN-2109-1 kernel 2014-02-18
Mandriva MDVSA-2014:001 kernel 2014-01-13
CentOS CESA-2013:X018 kernel 2013-12-28
openSUSE openSUSE-SU-2014:0247-1 kernel 2014-02-18
CentOS CESA-2014:0163 kvm 2014-02-12
Oracle ELSA-2014-3002 kernel 2014-02-12
openSUSE openSUSE-SU-2014:0205-1 kernel 2014-02-06
Fedora FEDORA-2013-23445 kernel 2013-12-21
Fedora FEDORA-2013-23653 kernel 2013-12-21
Mageia MGASA-2013-0375 kernel-vserver 2013-12-18
Mageia MGASA-2013-0373 kernel-tmb 2013-12-18
Mageia MGASA-2013-0374 kernel-rt 2013-12-18
Mageia MGASA-2013-0372 kernel-linus 2013-12-18
Mageia MGASA-2013-0371 kernel 2013-12-17
Scientific Linux SLSA-2013:1801-1 kernel 2013-12-16
Oracle ELSA-2013-1801 kernel 2013-12-12
CentOS CESA-2013:1801 kernel 2013-12-13
Red Hat RHSA-2013:1801-01 kernel 2013-12-12
Scientific Linux SLSA-2014:0163-1 kvm 2014-02-12
Oracle ELSA-2014-0163 kvm 2014-02-12
Red Hat RHSA-2014:0163-01 kvm 2014-02-12
Mageia MGASA-2014-0043 kernel-linus 2014-02-10
openSUSE openSUSE-SU-2014:0204-1 kernel 2014-02-06
SUSE SUSE-SU-2017:0437-1 the Linux Kernel 2017-02-09

Comments (none posted)

libiodbc: code execution

Package(s):libiodbc CVE #(s):
Created:December 17, 2013 Updated:December 18, 2013
Description: From the Slackware advisory:

This update fixes an rpath pointing to a location in /tmp that was found in two test programs (iodbctest and iodbctestw). This could have allowed a local attacker with write access to /tmp to add modified libraries (and execute arbitrary code) as any user running the test programs.

Slackware SSA:2013-350-01 libiodbc 2013-12-16

Comments (none posted)

llvm: code execution

Package(s):llvm CVE #(s):
Created:December 17, 2013 Updated:December 18, 2013
Description: From the Slackware advisory:

The LLVM package included binaries with an rpath pointing to the build location in /tmp. This allows an attacker with write access to /tmp to add modified libraries (and execute arbitrary code) as any user running the LLVM binaries. This updated package rebuilds LLVM to exclude the build directories from the rpath information.

Slackware SSA:2013-350-03 llvm 2013-12-16

Comments (none posted)

mit-krb5: denial of service

Package(s):mit-krb5 CVE #(s):CVE-2013-6800
Created:December 17, 2013 Updated:December 18, 2013
Description: From the CVE entry:

An unspecified third-party database module for the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) 1.10.x allows remote authenticated users to cause a denial of service (NULL pointer dereference and daemon crash) via a crafted request, a different vulnerability than CVE-2013-1418.

Oracle ELSA-2015-0439 krb5 2015-03-12
Scientific Linux SLSA-2014:1389-2 krb5 2014-11-03
Scientific Linux SLSA-2014:1245-1 krb5 2014-10-13
CentOS CESA-2014:1245 krb5 2014-09-30
Oracle ELSA-2014-1389 krb5 2014-10-16
Oracle ELSA-2014-1245 krb5 2014-09-17
Red Hat RHSA-2014:1245-01 krb5 2014-09-16
Red Hat RHSA-2014:1389-02 krb5 2014-10-14
Ubuntu USN-2310-1 krb5 2014-08-11
Gentoo 201312-12 mit-krb5 2013-12-16

Comments (none posted)

monitorix: three vulnerabilities

Package(s):monitorix CVE #(s):CVE-2013-7070 CVE-2013-7071 CVE-2013-7072
Created:December 13, 2013 Updated:December 18, 2013

From the Red Hat bugzilla entry:

The issue is that the built-in HTTP server failed to adequately sanitize request strings of malicious JavaScript. So by leveraging this issue, an attacker may be able to inject arbitrary cookies. The same issue could also cause arbitrary HTML and script code to be executed in a user's browser within the security context of the affected site. Input passed via requests to the "handle_request()" function (lib/ is not properly sanitised before being returned to the user. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site.

Fedora FEDORA-2013-22677 monitorix 2013-12-13

Comments (none posted)

mozilla: information leak

Package(s):mozilla CVE #(s):CVE-2013-6629 CVE-2013-6630
Created:December 12, 2013 Updated:June 6, 2016

From the Firefox advisory page:

Google security researcher Michal Zalewski reported issues with JPEG format image processing with Start Of Scan (SOS) and Define Huffman Table (DHT) markers in the libjpeg library. This could allow for the possible reading of arbitrary memory content as well as cross-domain image theft. (CVE-2013-6629, CVE-2013-6630)

openSUSE openSUSE-SU-2014:1645-1 java-1_7_0-openjdk 2014-12-15
openSUSE openSUSE-SU-2014:1638-1 java-1_7_0-openjdk 2014-12-15
openSUSE openSUSE-SU-2014:1100-1 Firefox 2014-09-09
Fedora FEDORA-2014-6859 mingw-libjpeg-turbo 2014-06-10
Fedora FEDORA-2014-6870 mingw-libjpeg-turbo 2014-06-10
SUSE SUSE-SU-2014:0733-2 IBM Java 7 2014-06-02
SUSE SUSE-SU-2014:0728-3 IBM Java 6 2014-06-03
SUSE SUSE-SU-2014:0733-1 IBM Java 7 2014-05-30
SUSE SUSE-SU-2014:0728-2 IBM Java 6 2014-05-30
SUSE SUSE-SU-2014:0728-1 IBM Java 6 2014-05-29
Red Hat RHSA-2014:0508-01 java-1.6.0-ibm 2014-05-15
Red Hat RHSA-2014:0509-01 java-1.5.0-ibm 2014-05-15
SUSE SUSE-SU-2014:0639-1 OpenJDK 2014-05-14
Red Hat RHSA-2014:0486-01 java-1.7.0-ibm 2014-05-13
Debian DSA-2923-1 openjdk-7 2014-05-05
Red Hat RHSA-2014:0412-01 java-1.7.0-oracle 2014-04-17
Red Hat RHSA-2014:0413-02 java-1.7.0-oracle 2014-04-17
Red Hat RHSA-2014:0414-01 java-1.6.0-sun 2014-04-17
openSUSE openSUSE-SU-2014:0065-1 chromium 2014-01-15
Fedora FEDORA-2013-23722 libjpeg-turbo 2014-01-10
openSUSE openSUSE-SU-2014:0008-1 seamonkey 2014-01-03
Fedora FEDORA-2013-23291 thunderbird 2014-01-02
openSUSE openSUSE-SU-2013:1918-1 MozillaFirefox 2013-12-19
openSUSE openSUSE-SU-2013:1917-1 MozillaFirefox 2013-12-19
openSUSE openSUSE-SU-2013:1916-1 MozillaFirefox 2013-12-19
openSUSE openSUSE-SU-2013:1959-1 thunderbird 2013-12-25
openSUSE openSUSE-SU-2013:1958-1 thunderbird 2013-12-25
openSUSE openSUSE-SU-2013:1957-1 thunderbird 2013-12-25
Fedora FEDORA-2013-23749 libjpeg-turbo 2013-12-24
Ubuntu USN-2060-1 libjpeg-turbo, libjpeg6b 2013-12-19
Slackware SSA:2013-350-02 libjpeg 2013-12-16
openSUSE openSUSE-SU-2013:1871-1 Mozilla 2013-12-13
Fedora FEDORA-2013-23127 firefox 2013-12-12
Fedora FEDORA-2013-23127 xulrunner 2013-12-12
Gentoo 201606-03 libjpeg-turbo 2016-06-05

Comments (none posted)

MRG: multiple vulnerabilities

Package(s):MRG CVE #(s):CVE-2013-4404 CVE-2013-4405 CVE-2013-4414 CVE-2013-4461
Created:December 18, 2013 Updated:December 18, 2013
Description: From the Red Hat advisory:

A flaw was found in the way cumin enforced user roles, allowing an unprivileged cumin user to access a range of resources without having the appropriate role. A remote, authenticated attacker could use this flaw to access privileged information, and perform a variety of privileged operations. (CVE-2013-4404)

It was found that multiple forms in the cumin web interface did not protect against Cross-Site Request Forgery (CSRF) attacks. If a remote attacker could trick a user, who is logged into the cumin web interface, into visiting a specially crafted URL, the attacker could perform actions in the context of the logged in user. (CVE-2013-4405)

It was found that cumin did not properly escape input from the "Max allowance" field in the "Set limit" form of the cumin web interface. A remote attacker could use this flaw to perform cross-site scripting (XSS) attacks against victims by tricking them into visiting a specially crafted URL. (CVE-2013-4414)

A flaw was found in the way cumin parsed POST request data. A remote attacker could potentially use this flaw to perform SQL injection attacks on cumin's database. (CVE-2013-4461)

Red Hat RHSA-2013:1852-01 MRG 2013-12-17
Red Hat RHSA-2013:1851-01 MRG 2013-12-17

Comments (none posted)

nbd: incorrect access control

Package(s):nbd CVE #(s):CVE-2013-6410
Created:December 12, 2013 Updated:December 18, 2013

From the Red Hat bug report:

Due to incorrect use of strncmp() in the parser for this file, however, it would allow clients to connect so long as their IP address in ASCII representation would start with something in the ACL file; e.g., would be allowed if was listed.

Ubuntu USN-2676-1 nbd 2015-07-22
Fedora FEDORA-2013-22610 nbd 2013-12-12
Fedora FEDORA-2013-22607 nbd 2013-12-12

Comments (none posted)

openjpeg: information leak

Package(s):mingw-openjpeg CVE #(s):CVE-2013-6053
Created:December 16, 2013 Updated:January 5, 2015
Description: From the Red Hat bugzilla:

Raphael Geissert discovered out-of-bounds memory read flaws in OpenJPEG. If a specially-crafted image were opened by an application linked against OpenJPEG, it could cause the application to crash or lead to information leaks.

Fedora FEDORA-2014-17053 openjpeg 2015-01-03
Gentoo 201412-24 openjpeg 2014-12-13
Fedora FEDORA-2014-0719 openjpeg 2014-01-31
Mandriva MDVSA-2014:008 openjpeg 2014-01-17
Fedora FEDORA-2014-0708 openjpeg 2014-01-14
Mageia MGASA-2014-0005 openjpeg 2014-01-06
Fedora FEDORA-2013-22914 mingw-openjpeg 2013-12-15

Comments (none posted)

openstack-nova: multiple vulnerabilities

Package(s):openstack-nova CVE #(s):CVE-2013-4469 CVE-2013-4463
Created:December 12, 2013 Updated:January 31, 2014

From the Red Hat bug reports:

Pedraig Brady from Red Hat additionally discovered that OSSA 2013-012 did not fully address CVE-2013-2096 in the non-default case where use_cow_images=False, and malicious qcow images are being transferred from Glance. In that specific case, an authenticated user could still consume large amounts of disk space for each instance using the malicious image, potentially also resulting in a Denial of Service attack on Nova compute nodes. (CVE-2013-2096)

Bernhard M. Wiedemann from SUSE reported a vulnerability in Nova's control of the size of disk images. By using malicious compressed qcow2 disk images, an authenticated user may consume large amounts of disk space for each image, potentially resulting in a Denial of Service attack on Nova compute nodes. (CVE-2013-4463)

Ubuntu USN-2247-1 nova 2014-06-17
Red Hat RHSA-2014:0112-01 openstack-nova 2014-01-30
Fedora FEDORA-2013-22693 openstack-nova 2013-12-12

Comments (none posted)

owncloud: security restriction bypass

Package(s):owncloud CVE #(s):CVE-2013-6403
Created:December 13, 2013 Updated:November 24, 2014

From the Mageia advisory:

Possible security bypass on admin page under certain circumstances and MariaDB (CVE-2013-6403).

Fedora FEDORA-2014-14066 php-sabredav-Sabre_VObject 2014-11-22
Fedora FEDORA-2014-14066 php-sabredav-Sabre_HTTP 2014-11-22
Fedora FEDORA-2014-14066 php-sabredav-Sabre_DAVACL 2014-11-22
Fedora FEDORA-2014-14066 php-sabredav-Sabre_DAV 2014-11-22
Fedora FEDORA-2014-14066 php-sabredav-Sabre_CardDAV 2014-11-22
Fedora FEDORA-2014-14066 php-sabredav-Sabre_CalDAV 2014-11-22
Fedora FEDORA-2014-14066 owncloud 2014-11-22
Mandriva MDVSA-2013:289 owncloud 2013-12-18
Mageia MGASA-2013-0367 owncloud 2013-12-12

Comments (none posted)

php: multiple vulnerabilities

Package(s):php5 CVE #(s):CVE-2013-6712
Created:December 12, 2013 Updated:December 18, 2013

From the Ubuntu advisory:

Stefan Esser discovered that PHP incorrectly parsed certificates. An attacker could use a malformed certificate to cause PHP to crash, resulting in a denial of service, or possibly execute arbitrary code. (CVE-2013-6420)

It was discovered that PHP incorrectly handled DateInterval objects. An attacker could use this issue to cause PHP to crash, resulting in a denial of service. (CVE-2013-6712)

Red Hat RHSA-2014:1765-01 php54-php 2014-10-30
Gentoo 201408-11 php 2014-08-29
CentOS CESA-2014:1012 php53 2014-08-06
Oracle ELSA-2014-1012 php53 2014-08-06
Oracle ELSA-2014-1012 php53 2014-08-06
Scientific Linux SLSA-2014:1012-1 php53 and php 2014-08-06
CentOS CESA-2014:1012 php53 2014-08-06
Red Hat RHSA-2014:1012-01 php53 2014-08-06
Mageia MGASA-2014-0162 php 2014-04-04
Mandriva MDVSA-2014:014 php 2014-01-21
openSUSE openSUSE-SU-2013:1963-1 php5 2013-12-27
openSUSE openSUSE-SU-2013:1964-1 php5 2013-12-27
Mageia MGASA-2013-0379 php 2013-12-19
Debian DSA-2816-1 php5 2013-12-12
Ubuntu USN-2055-1 php5 2013-12-12

Comments (none posted)

qt4: denial of service

Package(s):qt4-x11, qtbase-opensource-src CVE #(s):CVE-2013-4549
Created:December 18, 2013 Updated:May 2, 2014
Description: From the Ubuntu advisory:

It was discovered that QXmlSimpleReader in Qt incorrectly handled XML entity expansion. An attacker could use this flaw to cause Qt applications to consume large amounts of resources, resulting in a denial of service.

Mageia MGASA-2014-0263 qt3 2014-06-18
Gentoo 201403-04 qtcore 2014-03-13
Mageia MGASA-2014-0115 qt5 2014-03-03
openSUSE openSUSE-SU-2014:0125-1 libqt4 2014-01-24
Fedora FEDORA-2013-22883 qt3 2014-01-23
Fedora FEDORA-2013-22847 qt3 2014-01-23
Fedora FEDORA-2013-22932 qt 2014-01-22
Fedora FEDORA-2013-22860 qt 2014-01-22
Mageia MGASA-2014-0009 qtr 2014-01-17
openSUSE openSUSE-SU-2014:0070-1 libqt4 2014-01-15
openSUSE openSUSE-SU-2014:0067-1 libqt4 2014-01-15
Ubuntu USN-2057-1 qt4-x11, qtbase-opensource-src 2013-12-17
openSUSE openSUSE-SU-2014:0176-1 libqt5-qtbase 2014-01-31
openSUSE openSUSE-SU-2014:0173-1 libqt5-qtbase 2014-01-31

Comments (none posted)

rubygem-actionpack: cross-site scripting

Package(s):rubygem-actionpack CVE #(s):CVE-2013-6415
Created:December 18, 2013 Updated:December 18, 2013
Description: From the CVE entry:

Cross-site scripting (XSS) vulnerability in the number_to_currency helper in actionpack/lib/action_view/helpers/number_helper.rb in Ruby on Rails before 3.2.16 and 4.x before 4.0.2 allows remote attackers to inject arbitrary web script or HTML via the unit parameter.

Debian DSA-2888-1 ruby-actionpack-3.2 2014-03-27
Fedora FEDORA-2013-23636 rubygem-actionpack 2014-03-07
Red Hat RHSA-2014:0008-01 ruby193-rubygem-actionpack 2014-01-06
openSUSE openSUSE-SU-2014:0009-1 rubygem-actionpack-3_2 2014-01-03
openSUSE openSUSE-SU-2014:0019-1 rubygem-actionpack-2_3 2014-01-03
openSUSE openSUSE-SU-2013:1907-1 rubygem-actionpack-3_2 2013-12-18
openSUSE openSUSE-SU-2013:1906-1 rubygem-actionpack-3_2 2013-12-18
openSUSE openSUSE-SU-2013:1904-1 rubygem-actionpack-3_2 2013-12-18
openSUSE openSUSE-SU-2013:1905-1 rubygem-actionpack-2_3 2013-12-18

Comments (none posted)

rubygem-actionpack: multiple vulnerabilities

Package(s):rubygem-actionpack CVE #(s):CVE-2013-4491 CVE-2013-6414 CVE-2013-6417
Created:December 18, 2013 Updated:December 18, 2013
Description: From the CVE entries:

Cross-site scripting (XSS) vulnerability in actionpack/lib/action_view/helpers/translation_helper.rb in the internationalization component in Ruby on Rails 3.x before 3.2.16 and 4.x before 4.0.2 allows remote attackers to inject arbitrary web script or HTML via a crafted string that triggers generation of a fallback string by the i18n gem. (CVE-2013-4491)

actionpack/lib/action_view/lookup_context.rb in Action View in Ruby on Rails 3.x before 3.2.16 and 4.x before 4.0.2 allows remote attackers to cause a denial of service (memory consumption) via a header containing an invalid MIME type that leads to excessive caching. (CVE-2013-6414)

actionpack/lib/action_dispatch/http/request.rb in Ruby on Rails before 3.2.16 and 4.x before 4.0.2 does not properly consider differences in parameter handling between the Active Record component and the JSON implementation, which allows remote attackers to bypass intended database-query restrictions and perform NULL checks or trigger missing WHERE clauses via a crafted request that leverages (1) third-party Rack middleware or (2) custom Rack middleware. NOTE: this vulnerability exists because of an incomplete fix for CVE-2013-0155. (CVE-2013-6417)

Debian DSA-2888-1 ruby-actionpack-3.2 2014-03-27
Fedora FEDORA-2013-23636 rubygem-actionpack 2014-03-07
Red Hat RHSA-2014:0008-01 ruby193-rubygem-actionpack 2014-01-06
openSUSE openSUSE-SU-2014:0009-1 rubygem-actionpack-3_2 2014-01-03
openSUSE openSUSE-SU-2013:1907-1 rubygem-actionpack-3_2 2013-12-18
openSUSE openSUSE-SU-2013:1906-1 rubygem-actionpack-3_2 2013-12-18
openSUSE openSUSE-SU-2013:1904-1 rubygem-actionpack-3_2 2013-12-18

Comments (none posted)

thttpd: world readable logfile

Package(s):thttpd CVE #(s):CVE-2013-0348
Created:December 13, 2013 Updated:January 6, 2014

From the Novell bugzilla entry:

Agostino Sarubbo reported back in February that thttpd creates a world readable log file.

openSUSE openSUSE-SU-2014:0021-1 thttpd 2014-01-03
openSUSE openSUSE-SU-2013:1862-1 thttpd 2013-12-12

Comments (none posted)

webyast: privilege escalation

Package(s):webyast CVE #(s):CVE-2013-3709
Created:December 17, 2013 Updated:January 6, 2014
Description: From the SUSE advisory:

Local privilege escalation via secret rails tokens execution. This vulnerability was reported by joernchen of Phenoelit.

SUSE SUSE-SU-2014:0022-1 WebYaST 2014-01-06
openSUSE openSUSE-SU-2013:1954-1 webyast 2013-12-25
openSUSE openSUSE-SU-2013:1961-1 webyast 2013-12-25
openSUSE openSUSE-SU-2013:1952-1 webyast 2013-12-25
SUSE SUSE-SU-2013:1894-1 webyast 2013-12-16

Comments (none posted)

wireshark: denial of service

Package(s):wireshark CVE #(s):CVE-2013-5717
Created:December 17, 2013 Updated:December 18, 2013
Description: From the CVE entry:

The Bluetooth HCI ACL dissector in Wireshark 1.10.x before 1.10.2 does not properly maintain a certain free list, which allows remote attackers to cause a denial of service (application crash) via a crafted packet that is not properly handled by the wmem_block_alloc function in epan/wmem/wmem_allocator_block.c.

Gentoo 201312-13 wireshark 2013-12-16

Comments (none posted)

xen: denial of service

Package(s):xen CVE #(s):CVE-2013-6885
Created:December 17, 2013 Updated:March 28, 2014
Description: From the CVE entry:

The microcode on AMD 16h 00h through 0Fh processors does not properly handle the interaction between locked instructions and write-combined memory types, which allows local users to cause a denial of service (system hang) via a crafted application, aka the errata 793 issue.

Mageia MGASA-2015-0078 kernel-vserver 2015-02-19
Mageia MGASA-2015-0076 kernel-tmb 2015-02-19
Mageia MGASA-2015-0077 kernel-rt 2015-02-19
Mageia MGASA-2015-0075 kernel-linus 2015-02-19
Debian-LTS DLA-155-1 linux-2.6 2015-02-18
Debian DSA-3128-1 kernel 2015-01-15
Gentoo 201407-03 xen 2014-07-16
SUSE SUSE-SU-2014:0807-1 Linux Kernel 2014-06-18
openSUSE openSUSE-SU-2014:0766-1 Evergreen 2014-06-06
Mageia MGASA-2014-0238 kernel-vserver 2014-05-24
Mageia MGASA-2014-0236 kernel-tmb 2014-05-24
Mageia MGASA-2014-0237 kernel-rt 2014-05-24
Mageia MGASA-2014-0235 kernel-linus 2014-05-24
SUSE SUSE-SU-2014:0696-1 Linux kernel 2014-05-22
Mageia MGASA-2014-0229 kernel-vserver 2014-05-19
Mageia MGASA-2014-0228 kernel 2014-05-19
openSUSE openSUSE-SU-2014:0678-1 kernel 2014-05-19
openSUSE openSUSE-SU-2014:0677-1 kernel 2014-05-19
SUSE SUSE-SU-2014:0537-1 Linux kernel 2014-04-17
SUSE SUSE-SU-2014:0531-1 Linux kernel 2014-04-16
openSUSE openSUSE-SU-2014:0483-1 xen 2014-04-04
openSUSE openSUSE-SU-2014:0482-1 xen 2014-04-04
SUSE SUSE-SU-2014:0470-1 Xen 2014-04-01
SUSE SUSE-SU-2014:0459-1 Linux Kernel 2014-03-28
SUSE SUSE-SU-2014:0446-1 Xen 2014-03-25
SUSE SUSE-SU-2014:0411-1 Xen 2014-03-20
SUSE SUSE-SU-2014:0373-1 Xen 2014-03-14
SUSE SUSE-SU-2014:0372-1 Xen 2014-03-14
Scientific Linux SLSA-2014:0285-1 kernel 2014-03-13
Oracle ELSA-2014-0285 kernel 2014-03-13
Oracle ELSA-2014-0285 kernel 2014-03-13
CentOS CESA-2014:0285 kernel 2014-03-13
Red Hat RHSA-2014:0285-01 kernel 2014-03-12
Fedora FEDORA-2013-22866 xen 2013-12-16
Fedora FEDORA-2013-22888 xen 2013-12-16
CentOS CESA-2014:X005 kernel 2014-02-12

Comments (none posted)

xorg-server: code execution

Package(s):xorg-server CVE #(s):CVE-2013-6424
Created:December 18, 2013 Updated:January 22, 2014
Description: From the Debian advisory:

Bryan Quigley discovered an integer underflow in the Xorg X server which could lead to denial of service or the execution of arbitrary code.

Ubuntu USN-2500-1 xorg-server, xorg-server-lts-trusty, xorg-server-lts-utopic 2015-02-17
Oracle ELSA-2014-1982 xorg-x11-server 2014-12-11
Mandriva MDVSA-2014:020 x11-server 2014-01-22
Mageia MGASA-2014-0016 x11-server 2014-01-21
openSUSE openSUSE-SU-2013:1965-1 xorg-x11-server 2013-12-27
Scientific Linux SLSA-2013:1868-1 xorg-x11-server 2013-12-23
Oracle ELSA-2013-1868 xorg-x11-server 2013-12-20
Oracle ELSA-2013-1868 xorg-x11-server 2013-12-20
CentOS CESA-2013:1868 xorg-x11-server 2013-12-20
CentOS CESA-2013:1868 xorg-x11-server 2013-12-20
Red Hat RHSA-2013:1868-01 xorg-x11-server 2013-12-20
Debian DSA-2822-1 xorg-server 2013-12-18
Gentoo 201701-64 xorg-server 2017-01-25

Comments (none posted)

xtrabackup: poor encryption

Package(s):xtrabackup CVE #(s):CVE-2013-6394
Created:December 13, 2013 Updated:February 18, 2014

From the Novell bugzilla entry:

A fixed initialization vector (constant string) was used while encrypting the data. This opened the encrypted stream/data to plaintext attacks among others.

openSUSE openSUSE-SU-2013:1864-1 xtrabackup 2013-12-12
openSUSE openSUSE-SU-2014:0245-1 xtrabackup 2014-02-18

Comments (none posted)

zabbix: remote command execution

Package(s):zabbix CVE #(s):CVE-2013-6824
Created:December 13, 2013 Updated:January 23, 2014

From the Red Hat bugzilla entry:

It is found that if a flexible user parameter is configured in the agent, including a newline in the parameters will execute newline section as a separate command even if UnsafeUserParameters are disabled.

This type of attack is known to be only possible from Zabbix server or Zabbix proxy systems that are explicitly allowed in the agent configuration. Only flexible user parameters are vulnerable, static ones are not.

Fedora FEDORA-2014-5540 zabbix 2014-05-01
Fedora FEDORA-2014-5551 zabbix 2014-05-01
Gentoo 201401-26 zabbix 2014-01-23
Mageia MGASA-2014-0015 zabbix 2014-01-21
Fedora FEDORA-2013-22764 zabbix 2013-12-13

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel is 3.13-rc4, released by a slightly grumpy Linus on December 15. "So I delayed this a couple of days to get back to my normal Sunday release schedule, but I'm not entirely happy with the result. Things aren't calming down the way they should be, and -rc4 is bigger than previous rc's. And I don't think I can just blame the two extra days."

Stable updates: 3.12.5, 3.10.24, and 3.4.74 were released on December 11. The 3.12.6, 3.10.25, and 3.4.75 updates are in the review process as of this writing; they can be expected on or after December 20.

Comments (none posted)

Quotes of the week

Oh dear, you're asking me to read again through memory-barriers.txt (Xmas 2013 edition), and come to a conclusion. [...]

One of the problems with ACCESS_ONCE is that one easily falls into a mistaken state in which it seems to be necessary everywhere; but that illusion must be resisted.

The spinlock should make it unnecessary, but I'll have to muse on semi-permeable membranes, osmosis, stuff like that.

Hugh Dickins

Frankly, I wonder if we are trying to pack too much into one syscall - not just in terms of overloading it (that much is obvious), but in terms of trying to cram a sequence of syscalls into one. If we end up introducing new API(s) for mount(), it's probably worth considering something like this:

  • open a connection to fs type driver, get a descriptor
  • use normal IO syscalls (usually just write(2)) on that descriptor to tell fs type driver what do we want. If any kind of authentication is needed, that's the time for doing it
  • attach the thing identified by that descriptor to mountpoint
Al Viro ponders a better mount()

Comments (2 posted)

Kernel development news

Simple wait queues

By Jonathan Corbet
December 18, 2013
A "wait queue" in the Linux kernel is a data structure to manage threads that are waiting for some condition to become true; they are the normal means by which threads block (or "sleep") in kernel space. Over the years, the wait queue mechanism has evolved into a fairly elaborate and complicated kernel subsystem. Now, however, there is a move afoot to simplify that code, using a wait queue variant developed for the realtime tree; the result could be a fair amount of code churn in the kernel.

A look at <linux/wait.h> from the 2.0 kernel reveals a simple data structure: a basic linked list of waiting threads. A wake_up() call on a wait queue would walk the list, putting each thread into the runnable state; there was not a whole more to it than that. Then, in 1999, the infamous Mindcraft study pointed out some performance deficiencies in Linux; one of those was the "thundering herd" problem where multiple processes would be awakened and contend for a resource that only one of them could obtain. As a result, the "exclusive wait" functionality — where only the first of possibly many waiting threads would wake — was added. Then a callback mechanism was added in the 2.5 series so that the new asynchronous I/O facility could step in when things would otherwise block. And so on.

The end result is a data structure that is far larger and more complex than it was in the 2.0 days. It is the callback feature that was most problematic for the realtime tree, though; since those callbacks can sleep, they prevent the use of "raw" spinlocks to protect the wait queues themselves. To work around this problem, Thomas Gleixner created a new "simple wait queue" mechanism that would dispense with most of the added functionality and, thus, be suitable for use in the realtime kernel.

The 2013 Realtime Linux Workshop identified this code as a candidate for a relatively easy move into the mainline. In response, Paul Gortmaker has extracted the simple wait queue facility and posted the resulting patch series for review.

The code looks a lot like a return to the 2.0 kernel; much of the functionality that wait queues have gained in the meantime has been stripped away, leaving a familiar-looking linked list of waiting threads. There is no exclusive wakeup feature, no callback feature, and not much of anything else. What there is, though, is a wait queue mechanism that is sufficient for the needs of most wait queue users (of which there are many) in the kernel.

The API is similar to that of existing wait queues. Wait queue entries and wait queue heads are defined with:

    #include <linux/swait.h>


The low-level API, which requires a direct call to schedule() to put the calling thread to sleep, looks like this:

    void swait_prepare(struct swait_queue_head *head, struct swaiter *w, int state);
    void swait_finish(struct swait_queue_head *head, struct swaiter *w);

The swait_prepare() call is used to add the process to the given wait queue head and put it into the appropriate sleeping state. After performing any necessary checks and calling schedule(), the newly woken thread will call swait_finish() to remove itself from the queue and clean up.

The current wait queue implementation has an extensive set of macros to simplify the task of waiting for a condition; there is a similar, but much smaller set for simple wait queues:

    void swait_event(queue, condition);
    int swait_event_interruptible(queue, condition);
    void swait_event_timeout(queue, condition, timeout);
    int swait_event_interruptible_timeout(queue, condition, timeout);

Most of the other versions of wait_event(), including the "killable" variants, are not provided. It is amusing to look at a list of wait_event() macros that lack equivalents in the new API, just to see how this interface has grown over the years:

    wait_event_cmd(wq, condition, cmd1, cmd2);
    wait_event_hrtimeout(wq, condition, timeout);
    wait_event_killable(wq, condition);
    wait_event_lock_irq_cmd(wq, condition, lock, cmd);
    wait_event_lock_irq(wq, condition, lock);
    wait_event_interruptible_hrtimeout(wq, condition, timeout);
    wait_event_interruptible_exclusive(wq, condition);
    wait_event_interruptible_locked(wq, condition);
    wait_event_interruptible_locked_irq(wq, condition);
    wait_event_interruptible_exclusive_locked(wq, condition);
    wait_event_interruptible_exclusive_locked_irq(wq, condition);
    wait_event_interruptible_lock_irq_cmd(wq, condition, lock, cmd);
    wait_event_interruptible_lock_irq(wq, condition, lock);
    wait_event_interruptible_lock_irq_timeout(wq, condition, lock, timeout);

There is little impediment to adding "simple" versions of most of the above macros should the need arise; it will be interesting to see how many of them show up in the coming years. Needless to say, there is also nothing like the archaic sleep_on() interface; it is safe to say nobody will try to add a version of that.

Paul's posting notes that adding the simple wait queues makes the kernel smaller, even when they are only used in a couple of places. Given the size reduction and the relative simplicity of the interface, it is unsurprising that there has been no opposition to adding this code so far. The only real question is how that addition is to be done. Christoph Hellwig suggested that the simple wait queues could simply replace the current implementation, with the few places needing the fancier functionality being changed to use the older code under a new name. Paul, though, worried that such a wholesale change would create a flag day with problems being associated with the wait queue change in mysterious ways.

Nobody wants that kind of situation, so it seems more likely that simple wait queues will retain their "swait" naming scheme. The kernel might see a wholesale naming change for the existing wait queues to make it clear that there is now a choice to be made, though. Thus, we may see a large patch changing wait_event() to cwait_event(), and so on, without changing functionality; after that, individual call sites could be changed to simple wait queues at leisure. The result would be a fair amount of code churn, but that churn should leave a smaller and simpler kernel in its wake.

Comments (2 posted)

A proposal for "silent" port knocking

By Jake Edge
December 18, 2013

Port knocking is a longstanding technique to evade port scans that is typically implemented in user space. A recent patch proposed for the kernel would change that by adding support for port knocking into the TCP/IP stack itself. Beyond just allowing administrators to hide open ports, the patch would also provide some ability to thwart man-in-the-middle attackers either from making their own connections to those hidden ports or from hijacking those established by friendly clients. But the patch is facing some pushback from the network developers who think that user space is a better place to handle features like port knocking.

The details of the "knock" vary, but the basic idea for port knocking is that a protected port on a server will not respond to the normal connection-establishment protocol; instead, some special steps will be required to make a connection to the port. Those steps might include making a connection attempt to a different port, or to a series of ports, that show the server that the client knows the secret knock to gain entry to the clubhouse. Since port scanning programs generally don't know the secret knock and it is expensive to try lots of possibilities, the services behind the knock are hidden from view.

There are a few different reasons to hide a service. One is that the server program may have vulnerabilities, either because it has not been kept up-to-date or because there are unknown flaws in the code. If only trusted people know about the knock, it reduces the threat of someone exploiting the hole. In addition, hiding services like SSH will avoid brute-force username/password guessing attacks.

But there is another reason to hide the existence of a service: it may be illegal in certain jurisdictions or running it may draw unwanted attention to the host and its owner. Folks running Tor bridges or other privacy-oriented services may see them blacklisted by government-controlled internet service providers—or prompt a visit from some secret service.

Existing port knocking solutions generally either monitor firewall logs or capture packets from user space, then modify the firewall to open the port when the proper knock is detected. The Knock project—a part of the GNUnet project—looks to turn that on its head. With a few-hundred-line patch, authors Maurice Leclair, Julian Kirsch, and Christian Grothoff would move the port-knocking logic into the Linux networking stack. That would allow clients and servers to communicate, while hiding behind a port knock, simply by using the new TCP_STEALTH option to setsockopt(). If the code were widely available in most Linux kernels, users could rely on the feature being available, without having to install and configure some other port knocking solution.

Knock is different than other solutions in a couple of other ways. To start with, it is meant to be undetectable to a man in the middle. It just looks like a normal connection establishment to a particular port—there is no extra sequences of connections to other ports or other special knocks. It uses a technique called "silent knocking" that requires sharing a secret between the client and server using some unspecified, out-of-band mechanism. That secret is used to calculate the sequence number of the initial SYN packet that is sent to initiate the three-way handshake that starts TCP connections. Any SYN with an improper sequence number gets an RST reply; exactly what it would get for a closed port.

In addition, using the TCP_STEALTH_INTEGRITY option allows the the first bytes of the payload data to be protected by a hash-based message authentication code (HMAC), which effectively stops active man-in-the-middle attackers from hijacking the connection once it has been established. Essentially, the top 16 bits of the sequence number in the SYN packet correspond to the HMAC, while the low 16 bits are the authentication code that comes from the MD5 of the shared secret.

The 32-bit authentication code for stealth-only mode is calculated with one round of MD5 using the shared secret along with the destination IP address and port. In stealth+integrity mode, the client and server must agree on the number of payload bytes to be covered by the HMAC, which also uses MD5. A short paper [PDF] about Knock noted that using MD5 may be something of a surprise, but that it is already used by the kernel for initial TCP sequence number calculation as well as for SYN cookies. But in the linux-kernel mailing list thread, Jacob Appelbaum (who assisted in the design of Knock) was not particularly happy with the choice of MD5:

If we believe that MD5 is not secure, we should not use it. That others use it is not a strong reason to use it. Everyone should stop using MD5 - especially truncated MD5. :)

The stealth-only mode is vulnerable to replay attacks as a man in the middle can observe the proper sequence number to unlock the port and replicate it in their own packets (without knowing the secret). Stealth-only is also vulnerable to brute force attacks (trying all possible sequence numbers), but that could be expensive in terms of time and it is not particularly stealthy, so the attack might well be noticed. The stealth+integrity mode is more resistant, as the HMAC-protected bytes could be used to transfer a public key that is used to encrypt the rest of the data.

There are some other downsides to the idea that were briefly explored in the thread. For one thing, network address translation (NAT) implementations that change the sequence number in the SYN packet will not work at all with this technique. As David Miller pointed out, sequence number alteration is done in netfilter for tracking the SIP and FTP protocols as well as for virtual server load balancing.

Others were more explicitly suggesting that handling this kind of port knocking (or, seemingly, any kind of port knocking) would be best done outside of the TCP core—in user space. Both Stephen Hemminger and Andi Kleen suggested that user space was a better home for the code. But Grothoff, who signed off on the patch and posted it, was surprised by that attitude: "I mean, if this was a patch for GNU Hurd, I'd at least understand the strong urge to do everything in userspace". Kleen, though, noted that keeping port knocking in user space meant that "the risk of adding exploitable holes to the kernel is [significantly] lower".

Eric Dumazet was also critical of the idea. He suggested allowing user space to implement parts of the TCP protocol, which would also help other proposals (like TCP Minion):

With various proposals (like TCP minion), maybe its time to be able to implement part of TCP stack in user land (Keep the mux inside the kernel, and forward raw incoming packets to user land where all the crazy things can be done without kernel patching.)

Dumazet is also concerned that reusing the initial sequence number (ISN) will make it difficult for servers to distinguish duplicated packets. He didn't mention it, but duplicate ISNs (i.e. the sequence number sent with the SYN) might also make the port knocking more obvious to a man in the middle. Overall, though, Dumazet felt that the paper was too short to explore the idea: "You really need more than 3 pages to fully investigate all the pros/cons of this idea."

He also hinted at a possible direction for getting Knock upstream: looking at TCP fast open, which is somewhat similar and was merged into the mainline. If Knock could be more like fast open, or use it directly, it might have more of a chance to be added to the networking core. The concerns raised by Dumazet and others are reflections of the complexity of the networking stack, that there are a lot of moving parts all of which need to work well together. That's part of the reasoning behind relegating features like port knocking to user space.

On the other hand, Grothoff is not convinced that the small patch he posted "really warrants moving TCP into user land". But the reception from core network developers like Miller, Hemminger, and Dumazet would seem to make it fairly unlikely the patch will make it into the kernel. Working on ways to either move some pieces of TCP handling into user space or to extend netfilter to allow for both silent knocking and payload protection would likely be the best way forward. It is an interesting idea, though not without flaws, but getting it into the kernel itself is going to be an uphill battle.

Comments (10 posted)

Btrfs: Getting started

By Jonathan Corbet
December 17, 2013
LWN's guide to Btrfs
This is the second article in a series on the Btrfs filesystem; those who have not seen the first segment may wish to take a quick look. This installment will cover the basics of finding the requisite software and getting started with a Btrfs filesystem, while leaving the advanced features for the future. Using Btrfs as a simple Unix-style filesystem is a straightforward matter once the proper tools are in place.

The Btrfs filesystem code itself has been in the mainline kernel since the 2.6.29 release in early 2009. Since then, development of the in-kernel code has mostly been done upstream, so the mainline kernel contains all of the code that is deemed ready for use. In general, users wanting to use Btrfs for real work are probably best advised to stay close to the current mainline releases. Fixes are still being made at a high rate; it is probably preferable to run the fixed code than to get a demonstration of why the fixes were necessary. One can get even newer code by pulling from the Btrfs development repository, but that may be a bit too new for anybody who is not actively developing Btrfs.

The current user-space tools, which handle the creation and management of Btrfs filesystems, can be pulled from the repository at:


Until recently, the last "release" of btrfs-progs was 0.19, made in June 2009. Toward the end of November, though, the version number was set to "v3.12", inaugurating a new era in which version numbering will be tied to kernel releases. Btrfs developer Chris Mason noted at the time that he expected to make btrfs-progs releases with approximately the same frequency as the kernel going forward. Since much of the needed work is on the user-space side, this should be a welcome development for Btrfs users.

Once again, those wanting to make serious use of Btrfs are likely to want to run something close to the current versions of the supporting user-space utilities. A lot of work (and bug fixes) is going into this code, but one needs to stay current to take advantage of that work. Some distributions follow progress in the btrfs-progs repository more closely than others; Fedora 19 already has v3.12, for example, so there is no real need for Fedora users to build their own version. Users whose distribution does not track the btrfs-progs repository so closely may want to install their own version built from the repository.

Creating and mounting Btrfs filesystems

The utility to create a Btrfs filesystem is, unsurprisingly, mkfs.btrfs; it can be invoked directly or via the mkfs program. In its simplest form, it can be run as:

    mkfs.btrfs /dev/partition-name

Where partition-name is, of course, the actual name of the partition that is to contain the filesystem.

Naturally, mkfs.btrfs has a fair number of options, though fewer than some other filesystems offer. Some of those that are relevant for basic usage include --force (necessary to convince mkfs.btrfs to overwrite an existing filesystem on the target partition), --label to set a label, and --version to just print out the version number and exit. One can also specify --mixed to cause the filesystem to mix data and metadata blocks together. Normally that will slow things down, so it is only recommended for situations where space is at an absolute premium; the man page suggests only using it for filesystems up to 1GB in size.

Btrfs filesystems are made accessible via the mount command as usual. Like most non-trivial filesystems, Btrfs has a number of specialized mount options that can be used to control its behavior. Some of these options will be discussed in later installments; a few that are of general interest include:

Enables automatic defragmentation of the filesystem in the background while it is running. Comments in the documentation suggest that this feature is still under development and may not produce optimal results for all workloads.

compress [=zlib|lzo|no]
Turn on compression of data. With an argument, it specifies which compression algorithm should be used. The compress-force option forces the use of compression even on files that do not compress well.

Turns off the copy-on-write mechanism, but only for newly created files. Turning off COW removes an important integrity mechanism and disables compression and data checksumming. In a few situations (the documentation says "large database files") there may be a significant performance improvement, but most users will probably not want to use this option.

Turns off the creation of data checksums for newly created files.

A mounted Btrfs filesystem feels mostly like any other Linux filesystem. Every now and then, some differences leak out. It can be disconcerting, for example, to delete a large file and not see an increase in the amount of available free space. Look back a minute or two later, though, and the missing space will have reappeared — assuming, of course, that said large file does not exist in any snapshots. Btrfs does a lot more work in the background than many other filesystems do.

Other Btrfs tools

The btrfs-progs repository contains a number of programs beyond mkfs.btrfs. One of the more recent additions is the btrfsck filesystem check and repair tool. The man page makes the newness of this tool clear: "Considering it is not well-tested in real-life situations yet, if you have a broken Btrfs filesystem, btrfsck may not repair but cause additional damages." So users will want to think hard before running btrfsck in the --repair mode and, probably, make use of the "restore" functionality described below.

The lack of a battle-hardened btrfsck utility remains one of the top reasons why system administrators often shy away from this filesystem. But the sad truth is that the only way to really make a truly comprehensive filesystem repair tool is to observe, over time, the ways in which a filesystem can become corrupted and come up with ways to fix those problems. So btrfsck will eventually mature into a tool that can handle a wide variety of problems, but there are no easy ways to shortcut that process.

Meanwhile, anybody working with Btrfs will eventually need to make use of another tool, called simply btrfs. This tool is the Swiss Army Knife of the Btrfs world; it can be used to perform a wide variety of actions on a Btrfs filesystem. Thus, unsurprisingly, btrfs implements a large number of commands, many of which will be examined in the later parts of this series. A few that merit mention now are:

btrfs filesystem df filesystem
Provides free space information about the given filesystem with more detail than is available from the standard df command.

btrfs filesystem show [filesystem]
Print information about one or more of the available Btrfs filesystems.

btrfs filesystem defragment [file...]
Perform online defragmentation of a Btrfs filesystem; defragmentation is limited to the given files if they are specified.

btrfs restore device
This command will try to extract the data from the given device, which, presumably, contains a filesystem with problems. By using this tool prior to attempting to repair the filesystem with btrfsck, a system administrator can maximize the chances of retrieving the data from the device even if btrfsck fails badly. See this wiki page for details on how to use this tool.

btrfs scrub filesystem
Launch a "scrub" operation on the given filesystem; scrubbing involves checking metadata and data against the checksums stored in the filesystem and correcting any errors found. Scrubbing can take some time, needless to say; it can be paused and resumed with variants of the btrfs scrub command if need be.

btrfs send subvol
btrfs receive mount
Controls the send/receive functionality, which can be used to replicate filesystems remotely or to implement incremental backup operations.

The basics described thus far are enough to get started with Btrfs, treating it as just another Unix-style filesystem, possibly with added compression and data checksumming. But it's the advanced features of the Btrfs filesystem that make it truly unique in the Linux world. One of those features — the built-in multiple-device and RAID functionality — will be the subject of the next installment in this series.

Comments (13 posted)

Patches and updates

Kernel trees

  • Sebastian Andrzej Siewior: 3.12.5-rt7 . (December 18, 2013)
  • Sebastian Andrzej Siewior: 3.12.5-rt6 . (December 16, 2013)


Core kernel code

Development tools

Device drivers

Filesystems and block I/O

Memory management



Virtualization and containers


Page editor: Jonathan Corbet


The Android AppOps vanishing act

By Nathan Willis
December 18, 2013

Android users with concerns about protecting their private information against the prying eyes of installed apps got a welcome surprise recently: a framework for individually adjusting the privileges of separate apps appeared with little warning in Android 4.3. But, just as things were starting to look up for the privacy-conscious, the Android 4.4.2 release removed those same controls. Google claims that the framework appeared in Android by mistake; how exactly such a mistake happens is evidently left as an exercise for the readers. Just as importantly, the sequence of events leaves open serious questions about how the company intends to address user privacy.

Android 4.3 was released on July 24; although it was still codenamed "Jelly Bean" (as versions 4.1 and 4.2 had been before it), it did introduce a new API level with additional functionality. Part of that new functionality (API level 18) was a change to how permissions for installed apps could be managed. In previous releases, the Android app installer would prompt the user with a list of all of the permissions requested by an app (for example, access to address book contacts, access to geolocation data, access to SMS messaging, and so forth), and allow the user to decline if there was something suspicious about the requested permissions.

At least, that was the theory. In practice, though, there was never much the user could do about an app that requested too much information. The choice was all-or-nothing: install the app with all the permissions it asked for, or do without the app altogether. Many apps seemed to simply request all of the permissions the developers thought they could get away with; worse yet, there were some apps that demonstrably abused their permissions. The most famous case was "Brightest Flashlight," an allegedly simple "flashlight" app that actually harvested personal information from Android phones and transmitted it to a remote server. The US Federal Trade Commission eventually brought charges against the developers, who settled out of court.

So it was welcome news to many when it was discovered that Android 4.3 included a mechanism (called "AppOps") to switch individual permissions on or off on a per-app basis. With AppOps, one could install the latest amazing social networking tool without letting it harvest the address book, or even install Brightest Flashlight without fear.

Not many users were aware of the AppOps feature because it was not exposed in the user interface. But Peter Eckersley of the Electronic Frontier Foundation (EFF) posted an article on December 11 that showed readers how to take advantage of the feature with the help of a new app called AppOps Launcher. The app provided a convenient list of every installed app that was registered for each type of permission, and allowed the user to toggle each permission setting on or off. For the curious, there are screenshots of AppOps Launcher doing its thing on Eckersley's post and on the app's web page. Eckersley's post praised Google for the facility, noting that "Android was built from scratch to have quite a sophisticated and strongly enforced system of per-app permissions" which had never been fully realized, but that with the "awesome" new AppOps feature, Android had given its users a huge win and had pulled ahead of Apple's iOS on the privacy front. Obviously AppOps had uses beyond privacy protection alone (for example, cutting down unwanted network traffic), but privacy is one of EFF's charter concerns, so it received most of the focus.

That joy was short-lived, though. Android 4.4 (codenamed "KitKat" with API level 19) was released on October 31, and the 4.4.2 update on December 9 removed AppOps entirely. That release was two days before the EFF blog post about AppOps Launcher, but Android releases do take some time to roll out. It is tricky to determine exactly when AppOps Launcher was first available in the Google Play Store, but it does seem to have been around for a period of months, so it is not as if Google was taken by surprise when it appeared. Eckersley posted an update on the EFF blog in reaction to the move, criticizing Google's step backward. The post notes that EFF had contacted Google for an explanation about the removal, and was told that the AppOps mechanism itself was experimental and "had only ever been released by accident." In particular, Eckersley reported, Google said that using AppOps could break the functionality of the apps it was used to tweak.

Of course, "breaking" versus "fixing" depends largely on one's point of view in this case. As Eckersley put it, apps requesting most information that they do not genuinely need (such as a phone's IMEI number) would continue to work fine if given a fake all-zero data set. He then called on Google to restore AppOps, and even extend it to other controls (like disabling network access to an app and building in easy-to-use controls).

Is that likely to happen? It is difficult to say. The biggest mystery remains how AppOps got into Android 4.3 to begin with. The fact that it exists at all suggests that Google was working on it already; that might mean that the feature is still planned for a subsequent release. But that is speculative. It could just as easily have been an experiment that the Android team decided was not worth pursuing.

The whole incident also reveals some of the hidden dangers in the current mobile OS development and deployment scheme. To those who develop software, an x.x.N release is historically a minor update, not one that removes significant functionality. But it is also problematic that Android releases are pushed out to users' devices with very little real information about the changes they involve. And it is also clear (and noteworthy for Android developers) that Google's naming scheme for Android releases is, at best, confusing. Initially, each major release was denoted by a new codename ("Gingerbread," "KitKat," etc.); now the codenames no longer mean anything, and evidently the version numbers and API levels (which are not the same) do not tell the whole story, either.

The good news, of course, is that the code did make it into an open source release. That makes it possible for third-party Android derivatives like CyanogenMod and Replicant to include AppOps in future releases—and, indeed, CyanogenMod does expose AppOps controls in its upcoming CM11 release. In fact, even if Google leaves AppsOps out for good, the third party project can continue to develop it for quite some time. The reversion certainly attracted a lot of high-profile criticism (even from well-known kernel developers, for instance). Cory Doctorow observed that aftermarket projects like CyanogenMod have exerted positive pressure on Google before, most notably when CyanogenMod implemented tethering support and Google was forced to follow suit.

AppOps's availability in CyanogenMod is far from being any sort of guarantee; in recent months the project has added several new privacy- and security-related features (such as WhisperPush, discussed last week) that Google does not seem intent on emulating. But better privacy controls are a higher-profile issue; the inability to control per-app permissions has been discussed for years, and most users are at least aware that some apps overreach when requesting permissions—the permission confirmation pop-up window at least increases awareness. If Google does not see the light, though, users might just look for alternatives.

Comments (none posted)

Brief items

Distribution quotes of the week

But the problem is, of course, that it means letting go of an awful lot of OS licensing revenue up front. It might be necessary to take the hit now in order to stay in the game later. And that's what I'm betting Microsoft's new, post-Ballmer management won't have the nerve to do. They have a fistful of banana and they won't want to let go... even though there's a big gang of penguins closing in, with a mean look in their eyes and big clubs.
-- Liam Proven (Thanks to Erik Zeek)

The distributions make choices that are motivated, I'd like to think, by what's best for their users. But in so doing, they also have caused a kind of fragmentation that makes the distributions effectively proprietary, and as different as Windows is to OS X. The one commonality they share is the name of the kernel. It's actually quite disconcerting for people new to "linux" to find out the extent of mutual incompatibility that exists. Again, I don't think that's any upstream's design goal. Conversely, differentiation is a design goal for distributions.
-- Chris Murphy

Comments (none posted)

Debian 7.3 released

The Debian project has announced the third update of its stable distribution Debian 7 "wheezy". As usual, this point release contains important bug fixes and security updates.

Full Story (comments: none)

Fedora 20 released

The Fedora 20 release is out. "The Fedora Project dedicates the Fedora 20 release to Seth [Vidal] and asks that you join us in remembering his generous spirit and incredible work that helped make Fedora what it is today. We miss you, Seth." Click below for an overview of the many changes and new features in this release.

Full Story (comments: 13)

Announcing openSUSE Education Li-f-e 13.1

The openSUSE Education community has announced the release of openSUSE Education Li-f-e. It is based on the recently released openSUSE 13.1 with all the official online updates applied. "We have put together a nice set of tools for everyone including teachers, students, parents and IT administrators. It covers quite a lot of territory: from chemistry, mathematics to astronomy and Geography. Whether you are into software development or just someone looking for Linux distribution that comes with everything working out of the box, your search ends here."

Comments (none posted)

Valve SteamOS available

An initial unstable release of Valve's SteamOS distribution is available for download. A look at the SteamOS FAQ is recommended as a first step, though. It is based on Debian wheezy with some backports and proprietary bits added on top. There is a new custom compositor that only supports NVIDIA chipsets in this release.

Comments (56 posted)

Distribution News


A note for those upgrading to Fedora 20

Discussions on the Fedora mailing lists have made it clear that attempting to upgrade a machine to Fedora 20 with fedup 0.7 will end badly. The solution is simple enough: update fedup to version 0.8 before doing the upgrade; those upgrading from Fedora 18 should also pass the --nogpgcheck flag to fedup.

Comments (25 posted)

Cooperative Bug Isolation for Fedora 20

The Cooperative Bug Isolation Project (CBI) is now available for Fedora 20 on both x86_64 (64-bit) and i386 (32-bit) platforms. The Bug Isolation Project is a research effort designed to investigate software crashes. CBI distributes specially modified versions of popular open source software packages. These special versions monitor their own behavior while they run, and report back how they work (or how they fail to work) in the hands of real users.

Full Story (comments: none)

Reminder: Fedora 18 end of life

Now that Fedora 20 has been released, Fedora 18 is reaching its end of life. There will be no further updates for Fedora 18 after January 14, 2014. Note: use fedup 0.8 to upgrade.

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

Comments (none posted)

Bacon: Partners, Community, and Success

On his blog, Ubuntu community manager Jono Bacon looks at what new partners for Canonical (like the new, unnamed smartphone partner) mean for Ubuntu and its community. "If we have more users, we get more ISVs such as Adobe, Autodesk, Zynga, Rovio and others who want to use Ubuntu as a channel. If we get more apps from ISVs we get more interest from OEMs, carriers, and others. If we get more OEMs and carriers, we get more enterprise, creative-industry, and educational deployments. If we get more deployments we see more businesses selling support, services, training, people writing books, seminars, and other areas of focus. This effectively creates an eco-system around Ubuntu which in turn lowers the bar enough that any consumer can use and try it…thus putting Free Software in the hands of the masses."

Comments (32 posted)

Page editor: Rebecca Sobol


Breaking Python's API

By Jake Edge
December 18, 2013

A seemingly trivial change to a function in the Python standard library has led to a bit of a dilemma. The API clearly changed, which it is not supposed to do for a point release, but especially for the frozen 2.7.x branch. Any program that was using that part of the API was clearly ignoring documentation to the contrary, but once the change is out there, what is the proper course?

A change to the names of some parameters to the randrange() function was released in Python 2.7.6. Even though the parameters were documented to be private, they did not use the standard naming convention (starting with an underscore) to indicate that they were not part of the API. Meanwhile, at least one project was using those parameters.

The change was made in the Lib/ source file with a commit message that read (in part): "Minor clean-up of function parameters". The argument lists for three functions were changed along the lines of this change to randrange():

    -    def randrange(self, start, stop=None, step=1, int=int, default=None,
    -                  maxwidth=1L<<BPF):
    +    def randrange(self, start, stop=None, step=1, _int=int, _maxwidth=1L<<BPF):
The int and maxwidth parameters were changed to start with underscores and the default parameter was eliminated. In addition, the docstring for the function had the following line removed:
     Do not supply the 'int', 'default', and 'maxwidth' arguments.
So the idea is to explicitly name the parameters using the convention that says they are private, not part of the API, and not guaranteed to be backward compatible in the future. Once that is done, the documentation is no longer needed.

But, as Tres Seaver reported, that caused the Zope Object Database (ZODB) tests to fail. He noted the docstring warning, but also mentioned that passing "int=long" to randrange() is one way to have code that works for both Python 2.x and 3.x. The int parameter is used as the function to call to convert the parameters to integers. For Python 3.x, those integers are essentially longs. Python 2.7.6 was released with the change before the problem was detected.

Guido van Rossum didn't have much sympathy for the ZODB folks who "really, really should have known better". But Seaver pointed out that the code had been in that test since 2001.

Others were more sympathetic than Van Rossum, while still lamenting the choice that ZODB made. Barry Warsaw said that the change should be reverted or rewritten, and came up with a clever, but ugly, way to support both the old and new argument lists. But Tim Peters disagreed with the clever hack, noting that the performance of randrange() is "crucial for many applications".

In fact, the int parameter was put in as something of a performance enhancement. Looking up a global is much more expensive than looking up a local variable in Python. So, for a function like int() that gets called in an inner loop (as it does in randrange()), there is a significant performance boost from making it a local variable. Putting it in the parameter list means that the global lookup is done once at function definition time—all subsequent lookups are local.

Antoine Pitrou was also in favor of reverting the change, as were others. The only question then was how it should all be done. Donald Stufft was concerned that having a broken 2.7.6 version in the wild would be a problem. Others worried that telling users to go straight to 2.7.7 (which would have the fix) would cause them to delay upgrading, which would mean they are still vulnerable to any vulnerabilities that were fixed in 2.7.6.

Nick Coghlan said that reverting the change "means we do 2.7.7 ASAP so that *everyone* can just skip straight to 2.7.7". He also strongly suggested that changes like those made to randrange() not be done for point releases:

That kind of user visible change shouldn't have been made in a point release, regardless of what the docs said. It just isn't worth the risk of breaking the code of people that are relying on what's possible rather than what the docs say.

Van Rossum made a bet (for "a lavish dinner at PyCon") that it was only Zope/ZODB that used the int parameter. At the time it was done, he and other Python core developers were working for Zope "and we didn't always get our boundaries straight". It's not clear whether Daniel Holth's example will qualify as a winning entry, but some unmanned aerial vehicle (UAV) code has two instances of the following gem:

    random.randrange(0.0,1.0, int=float)
As Peters pointed out, that is just an expensive way to call random.random().

It's not yet clear what will be done about this problem, but reversion looks like the most likely outcome. Knowingly changing the API for a point release is clearly a bad idea, but this change doesn't quite fall into that bucket. It did, however, change the API, even if the documentation told developers not to use those parameters. That should likely have been enough to recognize that it wasn't the right time for a change of that sort.

Comments (1 posted)

Brief items

Quotes of the week

Remember kids, Orca knows (and speaks, and displays in braille) your secret UI hacks. :)
Joanmarie Diggs, advising careless coders that hidden labels aren't so hidden to the Accessibility Toolkit.

This is sort of fun as a way to walk through the visual history of GNOME but isn't a very nice face to present to the world.
Jon McCann on the downside of using static pages for GNOME's public web presence.

Back when PHP had less than 100 functions and the function hashing mechanism was strlen(). In order to get a nice hash distribution of function names across the various function name lengths names were picked specifically to make them fit into a specific length bucket. This was circa late 1994 when PHP was a tool just for my own personal use and I wasn't too worried about not being able to remember the few function names.
Rasmus Lerdorf

Lonely is the user who searches the Internet for an error message and only finds the source code that generates it.
"Command Line Magic" (hat tip to Reinout van Schouwen.)

Comments (none posted)

Subsurface 4.0 has been released

Subsurface 4.0 has been released. This is the first version to use the Qt toolkit. "This [switch to Qt] caused the need to do a complete rewrite of a large chunk of the Subsurface code base. We decided to keep much of the logic and core of the existing code around, but used the opportunity for quite a bit of cleanup and many improvements." Other features in this release include a new map widget to visualize dive locations, the ability to edit dives "in place", more data in the Dive Notes, a graphical editor for dive profiles, and more. See the release notes for details.

Comments (6 posted)

WordPress 3.8 availabile

Version 3.8 of the WordPress blogging platform has been released. This updates includes heavily redesigned administration tools (both for desktop and mobile browsers), changes to theme management, and a smoother interface for rearranging WordPress widget components.

Comments (none posted)

Rivendell 2.6.0 released

Version 2.6.0 of the Rivendell broadcast radio automation system has been released. Enhancements include a revamped audio import system, several new metadata fields for the audio library, and support for the NaturalLog logging platform. The update includes a change to the database schema as well, although the update tool should automatically convert older databases.

Full Story (comments: none)

Sphinx 1.2 released

Version 1.2 of the Sphinx documentation tool for Python has been released. This update adds Python 3.3 support, drops Python 2.4 support, and otherwise "includes about 50 features, several incompatible changes and fixes a lot of bugs/buglets." Nobody likes buglets, after all.

Full Story (comments: none)

Libgcrypt 1.6.0 released

Libgcrypt 1.6.0 is available. This update introduces an ABI change by removing the deprecated gcry_ac interface. Other changes include support for several new ciphers, including IDEA, Salsa20, and Salsa20/12, limited support for the GOST 28147-89 cipher, support for the GOST R 34.11-94 and R 34.11-2012 (Stribog) hash algorithms, and speed improvements to most cipher implementations.

Full Story (comments: none)

GNU Unifont 6.3.20131215 Released

A new version of GNU Unifont has been released. GNU Unifont supports the entire Unicode 6.3 Basic Multilingual Plane; the major change in this release is a set of scripts for converting between Unifont's hex format and PNG graphics. There is also new documentation in Texinfo format and the ability to generate sample fonts that include unassigned and Private use Area glyphs.

Full Story (comments: none)

Newsletters and articles

Development newsletters from the past week

Comments (none posted)

Packard: Cleaning up X server warnings

Keith Packard has been spending some time cleaning up X server compiler warnings. "So I was sitting in the Narita airport with a couple of other free software developers merging X server patches. One of the developers was looking over my shoulder while the X server was building and casually commented on the number of warnings generated by the compiler. I felt like I had invited someone into my house without cleaning for months — embarrassed and ashamed that we’d let the code devolve into this state. Of course, we’ve got excuses — the X server code base is one of the oldest pieces of regularly used free software in existence. It was started before ANSI-C was codified. No function prototypes, no ‘const’, no ‘void *’, no enums or stdint.h. There may be a few developers out there who remember those days (fondly, of course), but I think most of us are glad that our favorite systems language has gained a lot of compile-time checking in the last 25 years." His work is targeted for merging after the 1.15 release.

Comments (67 posted)

Page editor: Nathan Willis


Brief items

A new role in Open Invention Network (Google Open Source Blog)

On its open source blog, Google has announced that it has become a full member of the Open Invention Network (OIN). Google joins IBM, NEC, Novell (SUSE), Philips, Red Hat, and Sony as a full member of the organization. "OIN protects the open-source community through a patent cross-license for Linux and related open-source technologies. The license is free and available to companies, organizations, and individual developers if they agree not to assert their own patents against Linux. OIN also defends against anti-open-source patent aggression through education, reform efforts, and its own defensive patent portfolio. Over nearly three decades, what is now known as open-source software has benefited consumers all over the world by delivering innovative products and services. We’re committed to helping protect that innovation and are happy to expand our role in OIN." OIN also has a press release announcing Google as a new member.

Comments (2 posted)

Ada Initiative: End of year wrap-up

The Ada Initiative presents an update on its activities during 2013. "Overall, 2013 was a year of continuing progress for women in open tech/culture! Three recent high-profile incidents show how far we've come as a community: the controversy over removing unnecessarily gendered language in the open source project libuv, the debate over Chelsea Manning's name and gender in her Wikipedia entry, and two sexist presentations at the TechCrunch Disrupt conference."

Full Story (comments: 11)

Articles of interest

OpenHatch brings open source to campus (

Over at, Shauna Gordon-McKeon from OpenHatch looks at the non-profit's efforts to promote open source at various college campuses. These take the form of workshops that teach college students how to use version control and bug trackers, as well as how to make their first contribution. But the organization can't run all of the workshops they would like. "Our solution? Open Source Comes to Campus In a Box. We’re carefully documenting every part of our events, from the materials we present to the way we build our publicity websites, from food and space checklists to templates of all the emails we send. Our hope is that local organizers will be able to use our materials to run their own events, as has happened with our Python Workshops."

Comments (9 posted)

Calls for Presentations

Open Source Data Center Conference (OSDC)

OSDC will take place April 8-10, 2014 in Berlin, Germany. "Since the Call for Papers was opened in October, the first few speakers for the OSDC have been confirmed. This includes Logstash creator, Jordan Sissel who will present on the log management software. Lennart Koopman, founder of the Graylog2 project will also give a talk on the various methods of log analysis using the popular tool." The call for papers is open until December 31.

Full Story (comments: none)

ScilabTEC 2014

ScilabTEC will take place May 15-16, 2014 in Paris, France. The call for papers closes January 17. "The Conference Commitee welcomes abstracts on the main scientific domains using Scilab/Xcos for numerical computation such as automotive, aeronautics, space, energy, defense, telecommunications, biomedical, finance, transportation, environment."

Full Story (comments: none)

PGCon 2014 call for papers

PGCon 2014 will take place May 20-24, 2014 in Ottawa, Canada. The call for papers closes January 19. "If you are doing something interesting with PostgreSQL, please submit a proposal. You might be one of the backend hackers or work on a PostgreSQL related project and want to share your know-how with others. You might be developing an interesting system using PostgreSQL as the foundation. Perhaps you migrated from another database to PostgreSQL and would like to share details. These, and other stories are welcome. Both users and developers are encouraged to share their experiences."

Full Story (comments: none)

CFP Deadlines: December 19, 2013 to February 17, 2014

The following listing of CFP deadlines is taken from the CFP Calendar.

DeadlineEvent Dates EventLocation
December 31 April 8
April 10
Open Source Data Center Conference Berlin, Germany
January 7 March 15
March 16
Chemnitz Linux Days 2014 Chemnitz, Germany
January 10 January 18
January 19
Paris Mini Debconf 2014 Paris, France
January 15 February 28
March 2
FOSSASIA 2014 Phnom Penh, Cambodia
January 15 April 2
April 5
Libre Graphics Meeting 2014 Leipzig, Germany
January 17 March 26
March 28
16. Deutscher Perl-Workshop 2014 Hannover, Germany
January 19 May 20
May 24
PGCon 2014 Ottawa, Canada
January 19 March 22 Linux Info Tag Augsburg, Germany
January 22 May 2
May 3
LOPSA-EAST 2014 New Brunswick, NJ, USA
January 28 June 19
June 20
USENIX Annual Technical Conference Philadelphia, PA, USA
January 30 July 20
July 24
OSCON 2014 Portland, OR, USA
January 31 March 29 Hong Kong Open Source Conference 2014 Hong Kong, Hong Kong
January 31 March 24
March 25
Linux Storage Filesystem & MM Summit Napa Valley, CA, USA
January 31 March 15
March 16
Women MiniDebConf Barcelona 2014 Barcelona, Spain
January 31 May 15
May 16
ScilabTEC 2014 Paris, France
February 1 April 29
May 1
Android Builders Summit San Jose, CA, USA
February 1 April 7
April 9
ApacheCon 2014 Denver, CO, USA
February 1 March 26
March 28
Collaboration Summit Napa Valley, CA, USA
February 3 May 1
May 4
Linux Audio Conference 2014 Karlsruhe, Germany
February 5 March 20 Nordic PostgreSQL Day 2014 Stockholm, Sweden
February 8 February 14
February 16
Linux Vacation / Eastern Europe Winter 2014 Minsk, Belarus
February 9 July 21
July 27
EuroPython 2014 Berlin, Germany
February 14 May 12
May 16
OpenStack Summit Atlanta, GA, USA

If the CFP deadline for your event does not appear here, please tell us about it.

Upcoming Events

LCA2014 - Fourth Keynote

The team has announced a fourth keynote speaker, Dr Suelette Dreyfus. The conference will take place January 6-10 in Perth, Australia.

Full Story (comments: none)

Events: December 19, 2013 to February 17, 2014

The following event listing is taken from the Calendar.

December 27
December 30
30th Chaos Communication Congress Hamburg, Germany
January 6 Sysadmin Miniconf at 2014 Perth, Australia
January 6
January 10 Perth, Australia
January 13
January 15
Real World Cryptography Workshop NYC, NY, USA
January 17
January 18
QtDay Italy Florence, Italy
January 18
January 19
Paris Mini Debconf 2014 Paris, France
January 31 CentOS Dojo Brussels, Belgium
February 1
February 2
FOSDEM 2014 Brussels, Belgium
February 3
February 4
Config Management Camp Gent, Belgium
February 4
February 5
Open Daylight Summit Santa Clara, CA, USA
February 7
February 9
Django Weekend Cardiff Cardiff, Wales, UK
February 7
February 9 Brno, Czech Republic
February 14
February 16
Linux Vacation / Eastern Europe Winter 2014 Minsk, Belarus

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

Page editor: Rebecca Sobol

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds