LWN.net Weekly Edition for December 25, 2014

And so ends another year...

Welcome to the final LWN Weekly Edition for 2014. Following our longstanding tradition, we will not publish (what would have been) the January 1, 2015 edition; we'll return to our normal schedule on the 8th. We hope to return rested and ready to begin what will be, incredibly, LWN's 18th year. No doubt it will be an interesting one.

Another longstanding LWN tradition, of course, is to look back at our beginning-of-year predictions and to mock them mercilessly. Predictions, as they say, are hard, especially if you can't manage to get everybody to conveniently forget them before they can be proved wrong. Still, your editor was not entirely off-base back in January.

The first prediction was that 64-bit ARM-based servers would hit the market in 2014. That one was looking a bit uncertain for a while; these things always seem to take longer than one thinks they should. But, happily, HP came through at the end of September with its "Moonshot" offering. The associated prediction that ARM kernel developers would start to work more in the core kernel code is a bit harder to verify; there may be some movement in that direction, but the pace is glacial. For the most part, ARM developers seem happy to remain in their own subarchitecture-specific playgrounds.

Did we learn how bad the surveillance situation really is, as was predicted in January? That is, of course, impossible to verify (one might argue that this is the best kind of prediction). Your editor's sense, though, is that we still haven't learned about all that is going on, and that there will continue to be unpleasant surprises in the coming year. Addressing the related prediction: it does seem that awareness of free tools like Tor has grown. We are seeing the development of open-source whistleblower tools like GlobaLeaks and SecureDrop. Projects like the Open Wireless Router launched, but did not necessarily gain the success that their founders may have hoped for. It is certainly still true that the majority of computer users still do not understand how free software helps to defend their freedom in a highly networked world.

This year's predictions mentioned the fact that hardware is increasingly hard to trust. The appearance of BadUSB in August would appear to have borne that one out. This was an easy prediction, of course; in the end, our hardware is mostly software, so it will perforce suffer from the problems associated with software.

Was progress made against patent trolls as predicted? The answer would appear to be a cautious "yes." There were some encouraging rulings from the US Supreme Court, and there has been some evidence that the higher standards for "obviousness" are making themselves felt. As layoffs at Intellectual Ventures show, it is perhaps not the best time to be a patent troll. That said, the patent problem is far from solved; this is an issue we will have to stay on top of for many years yet.

With regard to Debian's init system debate, your editor was at least correct in saying that the project would choose systemd. The prediction that the issue would be resolved "early in 2014" proved to be sadly mistaken, though. What we have here is a failure to see just how divisive this question would be within the Debian community. Most distributions making the switch went through the seemingly obligatory mega-thread on their mailing lists, then made a decision and got on with life. There appears to be a substantial minority contingent within Debian that has no interest in getting on with life, though. Things have calmed down for now, but one should not look for predictions of continued calm from this direction.

Your editor predicted significant challenges for Android in 2014. In December, that prediction can safely be called a dismal failure. Android seems stronger and more unassailable than ever; even well-funded alternatives like Tizen do not appear to be going anywhere interesting. That is unfortunate; Android is a great system, but some serious competition might inspire it to become greater yet.

According to this report issued in July, Chromebooks account for 35% of all notebook sales. That is a surprising level of success that backs up the prediction that ChromeOS would have a good year.

As predicted, there was substantial debate on what makes a proper Linux distribution, with an emphasis on concerns over increasing divergence from "traditional Unix," whatever that could be said to be.

Btrfs, the predictions said, would start seeing wider production use in 2014. It is true that openSUSE 13.2 now uses Btrfs by default and takes advantage of the filesystem's features in some interesting ways. On the other hand, projects like CoreOS are looking hard at moving away from Btrfs after running into too many problems. Even people who warned that Btrfs would take a while to mature are, at this point, surprised at just how long it really is taking. The fact that Btrfs development seems to have slowed in recent months is worrisome as well. There is a real possibility that, by the time Btrfs is truly "ready," the world will have moved on to other solutions and forgotten about it.

Finally, we predicted that new kernel developers would become harder to find. Quantifying that situation is hard, but it is clear that the market for these developers remains robust. The fact that a substantial portion of new kernel developers are already employed by the time they get their first patch accepted suggests that companies are increasingly having to train developers themselves.

Beyond the Debian fiasco, what did your editor miss entirely this year? Arguably one of the more important issues in 2014 was the return of Big Security Issues. This was, after all, the year of "goto fail," Heartbleed, Shellshock, the as-yet unnamed NTP vulnerabilities, and numerous reports of large companies having their networks compromised with, usually, the disclosure of millions of credit card numbers. In many cases the actual vulnerabilities were quite old, but this is the year in which they were made public. It is fair to say that more people had to directly confront the consequences of security failures than have in recent years. Your editor would not dare to predict that this experience will create a greater awareness of security issues in the future, though.

A couple of other notes

Way back in 2002, we thought long and hard about whether we should add comments to LWN. We feared the worst, that trolls and others would turn the comment areas into vile cesspools and bring down the quality of the site in general, but, in the end, we added the feature anyway. For years, it seemed that our fears were unfounded; comments on LWN were generally polite and interesting.

It is difficult to be so upbeat about the experience at the end of 2014, though. Things have reached a point where we literally hesitate to post news items in certain hot-button topic areas for fear of the long and heated comment threads that will follow. Most LWN commenters do their best to remain polite and informative, but there are some clear exceptions. This year, for the second time in the site's entire history, we had to start deleting comments from one persistent, sock-puppet troll who would not get the message. That is not a step we take lightly and not something that is fun in general.

If we could ask for a holiday gift from our readers, it would be this: could we all please make an effort to improve the nature of LWN comments in the coming years? Asking trolls to stop is, of course, a pointless exercise, but the problem goes well beyond that. There are quite a few people out there with strong opinions about specific issues who feel the need to repeat their arguments, multiple times, often in marginally related conversations. Maybe we could all take the position that, once we've said our piece, there's little value in repeating it? Could we try harder to keep personal attacks out of the comments? Let us all try to reduce the noise a bit and let the signal shine through.

Finally, on a personal note: needless to say, I did not predict being diagnosed with a potentially life-threatening disease this year. I would like to thank all of you for both your support and your discretion in not making this whole thing an ongoing big deal on the site. I am pleased to announce that, some cleanup activities aside, I have just completed the rather unpleasant course of treatment prescribed by the doctors. Only time will tell for sure, but all of the indications at this point suggest a good outcome. 2015 will be a year of getting back into life and the community; I can hardly wait.

Special thanks are due to the LWN staff for keeping things running seamlessly during the times when I was otherwise occupied. Suffice to say they are all looking forward to a well-earned week off.

From all of us at LWN, best wishes to all of our readers for an outstanding holiday season and a great new year. You all are the reason we are here, and your support makes it all possible. We cannot adequately express our gratitude; we could not wish for a better group of people to write for and to share a community with.

Comments (32 posted)

Several vulnerabilities found in NTP

In yet another set of serious security holes disclosed in 2014, the network time protocol (NTP) project has reported a half-dozen vulnerabilities, some of which could lead to remote code execution. All of the vulnerabilities were found by two members of the Google Security Team (Neel Mehta and Stephen Roettger) and have been fixed in version 4.2.8 of the NTP daemon (ntpd). But that has led others to look into the ntpd code, only to find a situation akin to that of OpenSSL when Heartbleed was discovered: a huge, unwieldy code base that is probably too complex for what is needed on today's internet.

The vulnerabilities are, sadly, of a fairly pedestrian variety. Two are problems with generating random numbers using methods that do not provide good random numbers. Another is a programming error (missing return when an error is detected) that appears to be hard or impossible to exploit. The final three are the most worrisome, but also one of the more common vulnerabilities we have seen over the years: stack-based buffer overflows.

In all three of the buffer overflows, a remote attacker can send a maliciously crafted packet that could cause ntpd to execute arbitrary code. That could lead to a system running a vulnerable version of ntpd becoming a spam relay or a member of a botnet—or to full system compromise if ntpd is running as root. Even if it is not running as root, attackers may be able to get the access they want from a separate "ntp" user or they could use some kind of local privilege escalation and gain root privileges that way.

In all three cases, the noquery option in the /etc/ntp.conf configuration file can be used to mitigate the buffer overflow. That configuration will disallow other hosts from querying the server, thus avoiding the code paths where the buffer overflows occur. For most systems, that is likely to be just fine as they typically query some other server to get time information, but their administrators are not willing to serve up time to others. For many distributions, that is the default. It is probably only a tiny subset of systems that are actually serving time information, but for those systems, these vulnerabilities are potentially quite serious.

Over the years, ntpd has grown to have a huge number of features that are likely to be far beyond what the vast majority of NTP users actually need. Sub-millisecond accuracy, server capabilities with authorization mechanisms, and so on, may all be useful for some systems, some of the time, but many distributions have used ntpd as their NTP client or for situations where far less capable servers would easily do the job. By doing that, those systems were exposed to the much larger attack surface of ntpd, when something smaller—with a corresponding smaller attack surface—would suffice.

There are alternatives. Chrony is a simple NTP client and server that was originally written for systems that only connected to the internet sporadically and typically for brief durations. At the time it was written, ntpd could not really handle that type of internet access as it was geared to systems that were always connected.

The OpenBSD project wrote its own NTP client and server: OpenNTPD. According to Theo de Raadt, it did so after a conversation with the ntpd developers in which they refused his offer of help to audit the code. In that thread, the size of OpenNTPD was compared with that of ntpd, roughly 5k lines to 192k, which is an enormous difference, as De Raadt noted:

There is an effort underway to write a brand new NTP client and server: Ntimed. The work is being sponsored by the Linux Foundation as part of its Core Infrastructure Initiative, which is a post-Heartbleed effort to shore up the software that runs the internet. Poul-Henning Kamp is doing the work and has released a preview of the client in the wake of the disclosure of these ntpd vulnerabilities. In the project documentation, he explained why he was not simply fixing ntpd: "after studying the 300,000+ lines of source-code in NTPD, I concluded that while it could be salvaged, it would be more economical, much faster and far more efficient to start from scratch".

Those interested in following the progress of Ntimed may also find his blog of interest. He plans to eventually add more features, including server features, but how many and how quickly depends on "interest, skill, time and money". He hopes to have the first production release ready in the first part of 2015. The plan is to eventually turn Ntimed over to the Network Time Foundation for management as an open source project like it already does with ntpd.

There is a fair amount of inertia in our systems, along with an "if it ain't broke, don't fix it" mentality that may not be serving us well. In most cases, the code in question is broken, we just haven't looked hard enough to find it. Every time we do, we find more nasty little surprises like these.

Comments (23 posted)

XBMC becomes Kodi for version 14

Kodi, the free media-center project previously known as XBMC (and even more previously known as Xbox Media Center), has released version 14.0. As usual, the new release updates the list of supported multimedia codecs, but there are other changes to make note of as well. Some key annoyances in the behavior of extensions and on-screen keyboards have been eliminated, hardware-accelerated playback is improved, and there is new functionality. In an era where smart TVs and set-top boxes are seemingly springing up from every hardware and software vendor on the planet, Kodi would seem to be up against stiff competition—but the project continues to turn out releases that rival the best commercial offerings.

The new release is available for a variety of platforms. Binary packages for Ubuntu, Debian, Fedora, and OpenELEC are provided through distribution-specific repositories. In addition, there are official builds for Android and the Raspberry Pi, and there is the minimalist KodiBuntu distribution designed for deploying a standalone Kodi-specific device.

Perhaps it goes without saying, but the name change from XBMC to Kodi that accompanies this release constituted a major undertaking on the project's part. The reasons behind the decision were numerous, but they start with the connection to the Xbox, which is Microsoft's trademark, and which the Kodi project has long since left behind. Renaming the project reaches deep into the source code itself in places, in addition to the user interface, the documentation, and all of the various web properties. The wiki still has lingering references to the XBMC moniker in numerous places, but the application itself and all of the major add-ons seem to be fully caught up and XBMC-free.

Regardless of what one thinks of the Xbox, this is a good sign: the Kodi project is maturing and has outgrown its Microsoft-hardware roots. The rebranding reflects this well; "Kodi" might be a made-up word, but at least it is easily pronounced and does not instantly prompt a frustrating follow-up question (i.e., "what does that stand for?"). Even the new logo is nicely understated in comparison to its predecessor. As with previous releases, Kodi incorporates a robust add-on system that makes accessing online media services as smooth as accessing local files (with, of course, the perpetual issue of those commercial services that do their best to prevent access from Kodi's official add-ons).

Codecs and other low-level bits

Functionally, the biggest change in the 14.0 release is the bump to FFmpeg version 2.4.4, which introduces playback support for the H.265 and VP9 video codecs. Both are reputed to be significant improvements over their respective predecessors (H.264 and VP8), although it should be noted that H.265 comes with the usual concerns about whether it is wise to use patent-encumbered codecs promoted by royalty-collecting bodies. FFmpeg's H.265 support is based on the LGPLv2.1-licensed openHEVC, but it is entirely software-based. That means playback on low-resource devices like the Raspberry Pi or on battery-powered Android hardware could be problematic.

There are several other codec- or playback-related improvements in Kodi 14, though. One enhancement in the Video Acceleration API (VA-API), for example, should be beneficial to many users. VA-API now offers three new, advanced de-interlacing algorithms: motion-adaptive, motion-compensated, and FFmpeg's yadif (for "yet another de-interlacing filter"). There is, unfortunately, no one-size-fits-all method to decide which de-interlacing algorithm is best: it depends on the source and output and often boils down to personal preference. But all three of the new methods should produce more eye-pleasing results than the simple, more naïve approaches (like simply blending successive video frames). In another enhancement, 4K output is now supported on AMLogic system-on-chip (SoC) devices. Few 4K-capable playback devices are in wide distribution, but that number will surely climb.

There are also improvements in Kodi's support for the Consumer Electronics Control (CEC) protocol, which enables compatible devices to use their existing HDMI connection to send and receive commands. That effectively allows Kodi to function as a "universal remote" for CEC-compatible TVs, stereo receivers, and playback devices. The new features come courtesy of the libCEC library (which is also used by MythTV), and include the elimination of deadlocks whenever a CEC connection is lost, lower CPU usage, auto-detection and configuration of attached devices, and some hardware-specific updates to the support of Toshiba, Onkyo, and Raspberry Pi devices.

Finally, there have been a number of enhancements to the database functionality that sits beneath the user-visible media layer. Database cleanup jobs can be run in the background, cleanup itself has been sped up in general, and searching has been made more efficient. Users might notice these improvements at times, but they will more likely manifest themselves as the absence of annoying slowdowns while the user is trying to do something else.

Features

Kodi's main functionality is playing audio and video files, which is a task that the code has gotten so good at that it is difficult to notice major improvements between one release and the next. At this stage in the project's maturity, many of the user-visible improvements tend to fall into the "improved polish" category.

But there are a few areas where major functionality is still under development. In the Kodi 14 release, the prime example is the DVR (or PVR) feature: watching and recording broadcast television. The biggest addition to Kodi's DVR feature-set is support for digital subchannels on ATSC broadcasts (the over-the-air format used in North America). Kodi's electronic program guide (EPG) was also improved, though, adding API features that add-on developers can use to retrieve more detailed EPG information.

Several other minor DVR enhancements land in the new release as well. Kodi now remembers the last-visited folder of DVR recordings, which can save the user some folder-navigation hassle, and there is improved support for AM and FM radio tuners—which might sound out-of-place at first. Despite not being video sources, radio tuners are frequently integrated with broadcast TV tuners, so many DVR applications support both.

As far as other user-visible features go, the enhancement that will please the most users may be support for non-QWERTY keyboard layouts in Kodi's on-screen keyboard. There is not much hard data on how many Kodi users navigate the user interface entirely with a directional remote control as opposed to a wireless keyboard, but for those who do rely on the on-screen software keyboard, the inability to type Øs, Łs, ßs, or anything from the Cyrillic alphabet was, no doubt, an enormous frustration.

But even those users who only occasionally ran into a source of frustration in Kodi would be wise to try out the new release. The list of resolved issues includes a number of minor improvements. To highlight just a few: smart playlists (which allow users to create a playlist by filtering their media on an array of metadata fields) can now, for the first time, include multiple types of media content (that is, both audio-only and video). Universal Plug and Play (UPnP) servers are now listed in the main video library, rather than occupying a separate category. And it is now possible to launch a new add-on directly from within the add-on browser. In other words, the user can click "Install" to install a new media add-on (say, a new video service), then launch it immediately. In previous releases, the user would have to navigate back up the UI tree and go to whichever screen the new add-on had been installed to.

That final example probably sounds like a minor inconvenience at most, but in a very real sense, that is exactly the point: it is the assortment of minor inconveniences that separates a well-polished product from an "it works" project. Kodi has reached the point where its polish definitely rivals that of Roku, AppleTV, and other commercial smart-TV systems. Improvements like the latest-and-greatest assortment of codecs and specification compliance are necessary and important, to be sure. But it is the level of polish that makes an entertainment-focused application like Kodi either a joy or a pain to use.

People might put up with a little pain to watch the occasional bit of content in an obscure format, but they will not grant a painful application a permanent place in their media-viewing lineup. Kodi and XBMC before it have always excelled at providing a slick and polished way to access media content, whether that involves a local file or a remote web service that needs a separate add-on. The new 14.0 release keeps that tradition alive.

Comments (11 posted)