LWN.net Weekly Edition for November 3, 2011

ELCE11: Till Jaeger on AVM vs. Cybits

German lawyer Till Jaeger came to the Embedded Linux Conference Europe to update attendees on the AVM vs. Cybits case that is currently underway in Germany. The case has some potentially serious implications for users of GPL-licensed software, particularly in embedded Linux contexts, so Jaeger (and his client Harald Welte) felt it was important to publicize the details of the case. So important, in fact, that he and Welte are forgoing the usual practice of keeping all of the privileged information (between a lawyer and client) private.

Jaeger has also represented Welte in GPL enforcement cases based on the work the latter has done with gpl-violations.org. It is "clear I'm not neutral in this case", Jaeger said. The case is important to kernel developers, device makers, and to people using GPL software, he said, which is why they are publicizing it.

The dispute

AVM is a company that makes DSL routers called the "FRITZ!Box"—because anything named "Fritz" sells well in Germany, he said—which are based on Linux. These routers have 68% market share in Germany. Cybits offers a product to do internet filtering on the FRITZ!Box with its "Surf-Sitter" software. Surf-Sitter is installed on the router by the user downloading firmware from AVM, running a program that modifies the Linux kernel in the firmware and adding a user-space program to it, then installing the modified firmware onto the router.

AVM did not like that, Jaeger said, so it asked a court to prevent Cybits from distributing software that allowed a customer to change any software on the router. There are some side issues, like the changed firmware not blinking the lights of the device correctly when online, but the core issue is that nobody is allowed to change any software on the router, according to AVM's arguments. That is a "major attack on users' freedoms under the GPL", Jaeger said. It should not be possible to stop sales of software that changes the firmware on a device like the FRITZ!Box, he said.

In January 2010, a preliminary injunction was issued in a Berlin court that prevented Cybits from selling its software. That is when Welte got involved. In German civil law, it is possible to intervene in a case if you are concerned that your rights are not being upheld. Because Welte licensed his kernel code to both AVM and Cybits (i.e. under the GPL), he was able to intervene with Jaeger as his lawyer. When Cybits appealed the preliminary injunction, the court of appeals overruled most of the original decision, saying that Cybits could continue distributing its software as long as it doesn't cause technical problems with the router (such as the blinking lights problem).

At the same time, though, AVM filed another case in the Berlin regional court to, once again, stop Cybits from shipping its software. AVM won that case by default, because Cybits did not respond to the complaint in a timely manner. According to Jaeger, the company moved and the case fell through the cracks. Cybits then appealed the decision, which was considered at an oral hearing in June.

In that hearing, the details were discussed quite deeply, Jaeger said. The legal question had gotten more complicated because AVM had changed its claims, though the additional claims are not the interesting ones, he said. The main claim of interest is that you can't change any of the software installed on the router, including the GPL-covered software. Jaeger said that he asked AVM if it really meant to make that claim against the GPL software, and AVM affirmed that. He noted that Welte would probably not have intervened without the GPL claim. So far, there has been no decision, and he had hoped there would be one before the talk, but one is due sometime around November 1.

Legal questions

Jaeger's opinion is that if AVM prevails in its case, it will itself lose the right to distribute the kernel as it does on the FRITZ!Box. Because it will be imposing further restrictions than those embodied in the GPL, its license to distribute the GPL-covered parts will be automatically terminated. Because the GPL (version 2 in this case) clearly states that the source code includes the scripts used to control compilation and installation, it is clear that the intent is to enable the user to reinstall modified versions of the software, he said.

One member of the audience wondered whether the GPLv2 was sufficient to require AVM to allow its customers to change the firmware, as that was one of the things that the GPLv3 tried to address. Jaeger said that his interpretation of the GPLv2 was that it was sufficient to the task at hand, at least under German law. Another asked whether the Cybits software was free or proprietary, and he noted that it was the latter, but that there wasn't a GPL question about Surf-Sitter itself because it all ran in user space.

AVM has made several arguments about why the injunction should be upheld: trademark and copyright infringement, as well as unfair competition. One of the main questions that was discussed in the oral hearing in June seems silly to him: is the router a computer? AVM argued that it is not and that they are the only ones who should be allowed to change the firmware on the device. It is not a good argument in Jaeger's opinion, especially because the device is owned by the customer, so it is their property.

AVM claims to get more support calls from Surf-Sitter users than it does from users of unmodified FRITZ!Box routers. That is the basis of the unfair competition claim. It is an argument that the free software community would not like to hear Microsoft or HP make about installing free software on their systems, he said. If there were truly a support issue, AVM could refuse to support modified routers, so there is clearly more to it than that, he said.

The trademark claims are not really an issue in Jaeger's view, but the copyright infringement claims are more interesting. AVM argued that the firmware is a copyrighted work that cannot be changed without its permission, but Jaeger and Welte argued that the firmware is a derivative work of the GPL-covered kernel. AVM then changed its argument to say that the firmware was a collective work, but Jaeger believes that the GPL is intended to handle both derivative and collective works.

AVM is being contradictory in its behavior, he said, by claiming to be licensees of the kernel by releasing the source code as is required by the GPL, but then asserting claims that others cannot change the code. Those assertions constitute a GPL violation in his opinion, so that AVM will lose its rights to distribute the kernel if it prevails.

What's next?

When the court releases its decision, which could be any time now, it may render a judgement or reopen the case because of the additional claims made by AVM. If there is a final decision, either side can appeal, which is a likely outcome, he said. There may be an additional case eventually filed against AVM for violating the GPL. That could come from Welte or others, depending on how things play out, he said.

There were various audience questions about TiVo's technical measures to stop owners from changing the firmware (i.e. Tivoization) in relationship to this case. There are differences, Jaeger said, as AVM is trying to legally bar customers from changing the firmware, rather than using a technical measure (like cryptographically signing the binary as TiVo does). In his opinion, even the technical measure used by TiVo is a violation of the GPLv2, though he recognizes that there is a different interpretation in the US—something that led to some of the wording in the GPLv3. In Germany, Jaeger said, the court can dig into the intent of the license, in addition to its words.

Jaeger believes that what AVM really wants is an "Apple-like system" where it controls all of the software that runs on the device. But that runs afoul of its GPL obligations. AVM didn't write all of the software that runs on the FRITZ!Box, so it needs to comply with the licenses of the software it includes. That means allowing customers to modify the GPL-covered software contained inside, at least in Jaeger's view. We should know more about the case soon, but, whatever the outcome from the oral hearing, it seems likely that it will drag on for some time to come.

[ I'd like to thank the Linux Foundation for assisting with travel expenses to attend the conferences in Prague. ]

Comments (29 posted)

LCE11: UMMS, an audio/video abstraction layer

Geoffroy van Cutsem from Intel presented work on the Unified Multimedia Service (UMMS) on the first day of LinuxCon Europe. UMMS is a high-level abstraction layer for audio/video operations, which is meant to provide an API for application developers that is independent of both the playback engine used on the back end and of the output target. Van Cutsem described it as analogous to CUPS for printing or SANE for scanners.

UMMS was initially developed for the MeeGo Smart TV user experience (UX) and, although it will be developed from this point forward as a framework for the Tizen successor to MeeGo Smart TV, it could also be useful on desktop systems and other Linux environments. At present, the design covers media playback and basic media capture features, although more advanced features needed for the smart TV platform are on the roadmap.

As most end-users know, there is no shortage of video playback engines available for Linux: GStreamer, FFmpeg, Xine, MPlayer, and so on. However, they provide no uniform API: front-end applications must be specifically written to tie in to each back-end. Most application projects choose just one, and those that choose several undertake a major duplication in effort. For any particular engine there also need to be language-specific bindings and, in most cases, the application is still responsible for low-level details like constructing its own GStreamer pipelines.

Video capture is similarly fragmented. It requires the application to manage the capture hardware, and in the case of TV tuners, to know the format (DVB, ATSC, QAM, IPTV, etc) and manage the frequency tables and other tuning details. Commercial smart TV and set-top box OEMs also face a challenge when implementing video-on-demand (VOD) applications and playback engines for protected content streams like Blu-Ray in their products, because content-production companies demand isolating that code from GPL and LGPL modules.

UMMS is an attempt to solve all of these problems at once by constructing a consistent playback and capture API. It provides a D-Bus service, so it is both language-independent and capable of providing license isolation. There are playback, recording, and time-shifting functions, as well as methods to query media properties. Applications can access media by URI, without regard to whether the source is local or remote, whether it uses a protected VOD playback engine or GPLed media framework, or the output format used — including the availability of hardware acceleration for the file in question. The latter capability is intended to future-proof UMMS so that it can provide applications with transparent access to new advances in video processing; Van Cutsem cited processing video as OpenGL textures as one example.

Initial API

The project is currently hosted in the MeeGo build service, but Van Cutsem said it will be migrating to Gitorious soon. Unfortunately online resources for the work are still on the scarce side at the moment — there is a draft version of the requirements document on the MeeGo wiki, but the best documentation of the API itself is contained inside the spec/ directory of the source repository.

The API provides a way to create and manipulate "MediaPlayer" objects. Two types are available, "attended" or "unattended" MediaPlayer objects. For attended objects, the application must remain active during execution (as in most video playback scenarios), and can manipulate the video. With unattended objects, the application registers an event with UMMS, then shuts down. The canonical unattended example is scheduling a DVR recording: the application provides a "time to execute" to the UMMS service, along with an input URI and a destination file name.

The code from the MeeGo build service stands at version 0.0.1, and implements sample applications of each type. There is a media player using GStreamer as the back-end framework, and a video recorder that can schedule recordings from a DVB video source. UMMS is licensed under the LGPL v2.1.

Each MediaPlayer object supports methods to report the codec used, the height and width, the playback rate, whether the content is seekable, allowed (by the copyright holder) to be displayed at full-screen resolution, and the presence and location of all audio, video, and subtitle tracks (although much of the focus deals with video content, UMMS supports audio-only media just as easily). Applications can use UMMS to query or set the playback position, adjust volume or playback speed, and do basic fast-forward/reverse scrubbing.

UMMS defines a "target" as the output destination of any MediaPlayer stream. For PC usage, this would be either an X window or an OpenGL (or other hardware acceleration) pipeline. For direct connection to TVs, there are other considerations that mandate handling HDMI and other output signals differently — non-square pixels, overscan, and so on. But a target could also be a UI element inside of another application, for example a <video> object on a web page, in the case of a browser.

Although UMMS is designed to abstract away many of the details of a media file from the application, it may not always be possible. In a discussion on the meego-dev list in March, developer Dominig ar Foll explained that some content sources will still demand that the application inspect codec settings, bit rates, buffer depths, and other specifics — in order to manage hardware resources on the device. For example, some sources are expected to provide multiple video tracks using different codecs all in a single multiplexed stream, allowing the application to choose between them. The plan is for UMMS itself to also support automatically selecting the codec in such a situation, based on a pre-defined policy — such as whether an unoccupied hardware decoder for one codec is available, or whether hardware-decoding of a codec would consume less power than software-decoding of another.

Extending the concept

Beyond the basic playback and scheduled recordings already set out in the reference applications, the plan is to extend UMMS to cover a few other TV-specific features, starting with additional functions for DVR applications. There will need to be methods to work with electronic program guides (EPG), as well as to support time-shifting and conditional-access restrictions (think pay-per-view and VOD features, where the content provider might want to ensure that a media file is not watched multiple times).

Smart TVs must also implement industry standards like parental controls and channel locks. In some countries, this is not merely an issue of conforming to expectations, but of adhering to mandatory regulations. Finally, as in the codec-selection example above, one of the goals of UMMS is to provide a framework for managing hardware resources for access by multiple applications. Thus it will need to be able to report status back to applications when there are no tuners or decoders currently available, as well as distinguish between the capabilities of various playback and capture resources, and prioritize requests based on policies.

Although UMMS is designed to meet the needs of the smart TV UX, both Van Cutsem and the developers on the MeeGo lists emphasized that it will hopefully provide useful functionality to other form factors as well — in-vehicle systems and tablets in particular. But it fills in a gap in PC-based Linux systems, too. The ability to abstract away the playback engine would simplify development of desktop media players, especially those wanting to use hardware video decoding. TV capture cards are more of a specialty item, at least for now. However, the slow pace of development in the open source DVRs MythTV and Freevo could probably benefit from an abstraction layer like UMMS as well.

To be sure, a portion of the free software community may always grate at the prospect of building a framework that explicitly enables proprietary playback engines and applications, but UMMS is not substantially different from CUPS or other system frameworks in that regard. In this case, supporting the needs of set-top box makers who are beholden to the content industry bears dividends for open source, too, by clearly defining an API layer Linux has been missing for too long.

Van Cutsem ended his talk promising that more details would be coming online soon — UMMS happened to land at an awkward point in the transition between MeeGo and Tizen, after all. The MeeGo build system, lists, and wiki are slated to be taken offline in one year, but the Tizen project infrastructure has not yet rolled out. "Stay tuned" seems like the appropriate message.

[The author would like to thank the Linux Foundation for assisting with his travel to LinuxCon Europe 2011.]

Comments (16 posted)

The embedded long-term support initiative

The initiative was presented by Tsugikazu Shibata, a manager at NEC and a member of the Linux Foundation's board. According to Shibata-san, current long-term supported kernels do not really meet the embedded industry's needs. Those kernels are well suited to the needs of the enterprise distributions, where the same kernel can be used and supported for periods up to ten years. A number of those distributions are built on 2.6.32, which can expect to be supported for some time yet. Enterprise distributions last for a long time, so the kernels they use are picked rarely and supported for many years.

In the embedded world, 2.6.32 is very old news. Product lifetimes are much shorter for most embedded products; manufacturers in this area need a new, supported kernel every year. This industry, however, has no infrastructure for the support of kernels on that sort of schedule. Last year the industry came together and decided to standardize on 2.6.35, but it was a one-shot action; no plans were made to support any later kernel versions. That is a problem: but products being designed now are likely to need something newer than 2.6.35.

Another problem is that finding common ground for a standard embedded kernel is hard. Much of the industry is currently driven by Android, which releases with new kernels every six months or so. Manufacturers, though, tend to get their kernels from their suppliers; those kernels can be based on almost any version and lack any support going forward. Those manufacturers need that support. They also would really like to use the same kernel for a few generations of a product; that requires support for a period of a few years, but it also requires a certain amount of backporting of drivers and features.

Yet another problem, one that has characterized the embedded industry for years, is that there still are not enough contributions to the mainline from embedded developers (though, in all fairness, things have improved considerably). Manufacturers have a lot of patches in house, many of which do good stuff, but they are not going upstream. That imposes costs on those manufacturers, who have to carry those patches forward, and it impoverishes the mainline.

The LTSI project will have three components to address these problems. The first of those will be a long-term stable tree for the embedded industry. A new tree will be selected roughly once each year; 3.0 has been picked as the initial kernel in this series. Each long-term kernel will receive updates for two years as part of the usual stable update process; as with the other stable kernels, only bug fixes and security updates will be considered. Some sort of advisory board will be set up with a number of industry developers to pick subsequent stable kernels.

The second component will be the "LTS industry tree," which will be maintained, by CE Working Group members, independently from the regular stable updates. This is the tree that, it is expected, will actually be used in products. It will be based on the long-term releases, but will include some extras: backported drivers, perhaps some backported features, and various other vendor patches. In addition, there will be an associated "staging tree" where interesting code can be tested out prior to its inclusion in the industry tree. A separate quality assurance group will devote itself to testing the code in the staging tree and deciding when it can graduate.

The normal path for getting code into the industry tree will be to get it upstream; a backport can then be done. There is, however, an intended mechanism to take code directly via the LTSI staging tree in unusual or urgent cases. Shibata-san was clear, though, that "upstream first" will be the usual rule for this tree.

Finally, there will be an initiative to help industry engineers get their code upstream. Yet another staging tree will hold these patches while they are made suitable for inclusion into the mainline.

While it is assumed that the embedded industry is carrying a lot of code internally, nobody has ever really known for sure. To get a better handle on how much out-of-tree code exists, the Working Group launched the "Yami-nabe Project." Yami-nabe parties are, evidently, an old, no longer observed Japanese custom. Everybody would show up to a dark room containing a large pot of water; each would bring some item of food and toss it in. Everybody would then eat the resulting soup without knowing what was in it or where it came from - whether they liked it or not.

The modern form of a Yami-nabe party, it seems, involves collecting out-of-tree patches from manufacturers without tracking where they came from. None of the companies involved want to have their work compared to that of others. The collected code was examined to see how much of the kernel had been modified, and how much duplicated code there was. Turns out there were a lot of files in the kernel that most or all manufacturers felt the need to modify; much was in architecture-specific and driver code, but there were a lot of core kernel code changes too. Quite a few vendors had made similar changes in the same places.

So clearly there is some duplication of effort going on. The LTSI tree, Shibata-san said, should help to reduce this duplicated effort and to reduce the kernel fragmentation in the embedded industry. Throw in some help with the upstreaming of code and, they hope, fragmentation in this area can be eliminated entirely - or at least something close to that.

The first kernel will be 3.0-based which is, not coincidentally, the base for the Android "ice cream sandwich" kernel. They hope to have an industry kernel release available sometime in the first half of 2012. After that, it's a matter of seeing what kind of uptake there is in the embedded industry. It seems, though, that quite a few companies are interested in this project, so the chances that they will at least look at its output are pretty good.

[Thanks to the Linux Foundation for supporting your editor's travel to Prague to attend this event]

Comments (63 posted)

Page editor: Jonathan Corbet

Security

Calibre and setuid

Programs that regular users can run with root privileges (i.e. setuid programs) are tricky to write correctly, which is why they are best avoided whenever possible. But there are, of course, things that users need to be able to do that require privileges (changing passwords is a canonical example), which is why the setuid/setgid facility exists in Unix. When the need arises, however, a great deal of care should be taken before writing and releasing a program that is meant to be installed as setuid (aka SUID). A recent bug report for the Calibre e-book reader shows the kinds of problems that can come about if proper care is not exercised.

Jason Donenfeld reported several bugs in the setuid calibre-mount-helper program to the project's Launchpad bug tracker on November 1. Essentially, the program is meant to allow Calibre users to mount various removable devices (like e-book readers connected via USB) to update the content on readers. Unfortunately, it suffered from five separate problems that Donenfeld reported, some of which could be easily used as a local privilege escalation—to root.

The problems themselves read like a laundry list of things not to do in a setuid program including not sanitizing user input, not setting the PATH environment variable before calling exec(), and not sanity checking arguments. It's not completely surprising that Calibre got these things wrong, as they are fairly common programming mistakes. For programs running with a user's privileges, those kinds of errors typically just lead to bugs of various sorts (some of which could have fairly catastrophic consequences for the user, but not the system as a whole). For setuid programs, though, errors like those can lead to very serious security holes—as they did here.

Something that was a bit surprising was the combative tone that Calibre's lead developer Kovid Goyal took in the comments on the bug. Rather than working with Donenfeld to see what the problems were, he dismissed most of the bugs as invalid. Even after Donenfeld tried to further point out the problems, Goyal was rather sarcastic in response:

The proof-of-concept that Donenfeld posted with the bug—fairly snarky in tone, which may not have helped—clearly showed how to exploit the lack of PATH sanitization to get root privileges, but didn't demonstrate a different reported problem with argument injection to the mount program. That particular problem results from not sanitizing the user input and passing it on to mount. The other three problems (arbitrary root-owned directory creation, arbitrary empty directory removal, and creating .created_by_calibre_mount_helper files anywhere in the filesystem) are going to be harder to exploit, but they certainly aren't capabilities that regular users should have.

Goyal fixed the PATH issue immediately, but didn't see the argument injection problem, and therefore didn't fix it. Dan Rosenberg pointed out that there was still a bug:

In addition, Rosenberg suggested that there were safer ways to allow users to mount removable media, rather than writing a setuid application specific to Calibre. Once again, though, Goyal takes the combative approach. He committed a fix (though it doesn't really solve the problem) for the problem of "mounting on top of important directories", but seems affronted by the bug comments:

Part of the problem is that Goyal is looking for a single solution to the mounting problem that works "on *every single linux distro that the current technique works on* not just version >= x of distro y". While that complaint has some merit, it is hardly an excuse to introduce security holes into the system. Though Goyal claims to be aware of the "dangers" of setuid programs, the code in calibre-mount-helper does not really bear that out.

In fact, Donenfeld quickly came back with an example exploit that routed around Goyal's fix. The fix just disallows mounting in /usr, /bin, or /sbin, but Donenfeld's example mounts a /etc filesystem (with a chosen root password in passwd), thus allowing the user to log in as root. Obviously, /etc can be added to the disallowed list, but that becomes something of an arms race. A whitelisting approach might be more reasonable, but a better solution would be to use the distribution-supplied mechanisms for mounting the e-book readers. Those solutions should have had most of the obvious (and some non-obvious) problems shaken out, though there is no universal cross-distribution mechanism as Goyal would like to see.

As Donenfeld points out, Debian does not install the mount helper, and instead uses a wrapper script around udisks. Fedora also avoids the mount helper. Judging from this bug report, Ubuntu has picked up the Debian fix as well. It is unclear whether any of those distributions made an effort to get the word out about the problem or get a fix upstream. openSUSE seems to install calibre-mount-helper, however, and various other distributions may as well. In any case, anyone who picks up the source package and installs it will get the program installed as a setuid binary in /opt/calibre/bin.

Writing secure code is hard. Programmers tend to focus on what they are trying to accomplish, rather than all of the different ways the program can be abused. That's not an excuse, but it is an explanation of sorts. Distributions and users should be especially vigilant about setuid programs that come in from packages that, arguably anyway, shouldn't need them. Projects should probably also try to engage with folks that report security problems, rather than attacking them.

As of this writing, the Calibre trunk is still vulnerable to the example exploit that Donenfeld posted. One would expect to see a fix for it soon, and that any distributions that install calibre-mount-helper to issue updates. Users that have it installed from source may want to investigate using a wrapper script or other means to disarm the bug until the fix is made, at least on shared machines.

Comments (17 posted)

Brief items

Security quotes of the week

Comments (none posted)

Blaze: Key escrow from a safe distance

Comments (3 posted)

New vulnerabilities

backuppc: cross-site scripting

Comments (none posted)

chromium: multiple vulnerabilities

Comments (3 posted)

empathy: cross-site scripting

Comments (none posted)

kernel: file corruption

Comments (none posted)

phpldapadmin: multiple vulnerabilities

Comments (none posted)

python-django: multiple vulnerabilities

Comments (none posted)

radvd: multiple vulnerabilities

Comments (none posted)

simplesamlphp: xml encryption weakness

Comments (none posted)

squid: denial of service

Comments (none posted)

tor: information disclosure

Comments (none posted)

wireshark: multiple vulnerabilities

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

Stable updates: no stable updates have been released in the last week. The 2.6.32.47 and 2.6.33.20 updates are in the review process as of this writing; they can be expected on or after November 4. Both are significant updates with over 100 fixes. 2.6.33.20 is expected to be the last update for 2.6.33 (for real this time); realtime users are encouraged to move to 3.0, which will be supported as a long-term release.

Comments (none posted)

Quote of the week

/*
 * More smoking hash instead of calculating it, damn see these
 * numbers float.. I bet that a pink elephant stepped on my memory.
 */

/*
 * Can't be having no nameless bastards around this place!
 */

/*
 * What it says above ^^^^^, I suggest you read it.
 */

/*
 * Plain impossible, we just registered it and checked it weren't no
 * NULL like.. I bet this mushroom I ate was good!
 */

/*
 * I took it apart and put it back together again, except now I have
 * these 'spare' parts.. where shall I put them.
 */
 
/*
 * We had N bottles of beer on the wall, we drank one, but now
 * there's not N-1 bottles of beer left on the wall...
 */

Comments (22 posted)

(Partially) graduating IIO

The core IIO code sat out of tree for a long time; the state of the code, it is said, reflected that fact. There has been a determined effort to improve things in the staging tree, with some measurable results. There is now a set of core IIO patches that, according to maintainer Jonathan Cameron, is now ready to move out of staging and into the mainline proper.

IIO sensors vary a lot, from simple, low-bandwidth sensors to complex, high-bandwidth devices. The initial IIO move is aimed at the first set. For this kind of sensor, the user-space interface is expected to live entirely in sysfs, under /sys/bus/iio/devices. Each device entry will have a number of attributes; some, like name and sampling_frequency, will be present for all sensors. Others will depend on what the sensor actually measures; the proposed ABI attempts to standardize the names of those attributes wherever possible.

The plan is to get this core interface into the mainline, then to start moving the simpler (and cleaner) drivers after it. Support for more complex devices will come later. As of this writing, this code has not been pulled for 3.2, but that could yet happen. Meanwhile, vast numbers of IIO changes have gone into the staging tree for 3.2; there is clearly a lot of interest in getting this subsystem into shape.

Comments (2 posted)

Kernel development news

3.2 merge window, part 1

The most significant user-visible changes merged for 3.2 include:

• The TCP stack now supports proportional rate reduction, an algorithm which allows for faster recovery after transient network problems.

• Support for persistent alias names for disk devices has been added to the block layer.

• The TOMOYO security module can now implement restrictions on environment variable names and socket operations.

• The extended verification module subsystem, which uses the trusted platform module to protect a system against offline modifications to files, has been merged.

• The CFS bandwidth controller, allowing an administrator to set maximum CPU usage for groups of processes, has been merged. See the documentation file for information on how to use this feature.

• RAID 5 support has been added for object-storage devices. This is the third RAID 5 implementation in the kernel, with another (for btrfs) due to arrive in the near future.

• The s390 architecture has gained kernel crash dump support.

• The cross-memory attach facility, meant to provide for fast interprocess messaging, is now in the mainline. The form of the system calls has changed since this patch was last covered here, though:

      ssize_t process_vm_readv(pid_t pid, const struct iovec  *lvec, 
  			     unsigned long liovcnt, const struct iovec *rvec,
  		 	     unsigned long riovcnt, unsigned long flags);
  
      ssize_t process_vm_writev(pid_t pid, const struct iovec  *lvec, 
  			      unsigned long liovcnt, const struct iovec *rvec,
  		 	      unsigned long riovcnt, unsigned long flags);
  

  See the man page for more information.

• The mremap() system call now works properly with transparent huge pages, reducing the number of page-split operations.

• The x86 architecture has gained an SSSE3-optimized implementation of the SHA1 hash algorithm. From the changelog: "With this algorithm I was able to increase the throughput of a single IPsec link from 344 Mbit/s to 464 Mbit/s on a Core 2 Quad CPU using the SSSE3 variant -- a speedup of +34.8%." Optimized implementations of Blowfish and Twofish have been added as well.

• There is a new user-space configuration interface for the crypto layer. Unfortunately, the implementers do not yet appear to have gotten around to writing any documentation for this interface.

• Support for the "Hexagon" DSP-based architecture has been merged; see this article for more information.

• DVFS ("dynamic voltage and frequency scaling") is a new mechanism for controlling devices that can operate at multiple voltage and frequency values, trading off between power consumption and performance as required. It is analogous to the cpufreq governor mechanism used for the CPU.

• New device drivers:
  • Processors and systems:: Analog Devices EVAL-ADAU1373 boards, RSI Embedded Webserver boards, Calao USB-A9G20 boards, Samsung EXYNOS4212 SoC processors, Samsung SMDK4412 boards, Picochip picoXcell-based boards, OMICRON electronics DEVIXP, MICCPT, and MIC256 boards, DENX M28EVK boards, Vision Engraving Systems EP9307 systems, and Calxeda Highbank-based boards.

  • Block: Realtek RTS5139 USB card readers and Marvell Universal Message Interface devices.

  • Graphics: SMSC UFX6000/7000 USB framebuffer devices, Aeroflex Gaisler framebuffer devices, and Samsung SoC EXYNOS series graphic units.

  • Input: BMA150/SMB380 acceleration sensors, Wiimote accelerometer and IR devices, and Bachmann electronic TSC-10, 25 or 40 serial touchscreens.

  • Media: Wolfson Micro WM5100 low-power audio subsystems, Analog Devices ADAU1373 audio codecs, Au1000/Au1500/Au1100 audio controllers, ITE IT913x demodulators and tuners, Aptina MT9P031 and MT9T001 sensors, NXP TDA10071 DVB-S/S2 demodulators, Conexant CX24118A tuners, TOPRO USB cameras, Pinnacle PCTV HDTV Pro USB devices, and TT Connect S2-3600 cards.

  • Miscellaneous: Incite Technology USB-DUXsigma data acquisition boards, Qualcomm PM8xxx-base vibrator devices, Analog Devices AD7280A lithium ion battery monitoring devices, Analog Devices AD7190, AD7192 and AD7195 analog to digital convertors, Wiimote rumble and force-feedback devices, TI PICO DLP mini-projector devices, Samsung EXYNOS4 thermal management units, Linear Technologies LTC2978 hardware monitoring systems, ePAPR hypervisor byte channels, Renesas TPU LED controllers, and GPIO-controlled regulators.

  • Networking: Marvell PCIE 8766 wireless adapters.

  • USB: Marvell PXA168 on-chip EHCI HCD controllers and DesignWare USB3 DRD controllers.

  • Note also that the ath6kl wireless driver, the brcm80211 wireless driver, the tm6000 V4L2 driver, the Altera FPGA firmware download module, and the core hyper-v driver have graduated from the staging directory into the mainline.

Changes visible to kernel developers include:

• The network drivers directory (drivers/net) has been massively rearranged with most drivers moved into media-specific or protocol-specific subdirectories.

• The new "pin control subsystem" allows developers on embedded systems to configure the many multi-purpose pins found on contemporary system-on-chip processors. See Documentation/pinctrl.txt for the details. Drivers for the U300 and CSR SiRFprimaII pinmuxes have been added as well.

• The new module_platform_driver() macro can eliminate a bunch of boilerplate code for simple platform drivers.

• The power management quality-of-service API has grown a new capability for the management of per-device QOS constraints; it is intended to be used with the new DVFS subsystem. See Documentation/power/pm_qos_interface.txt for details on this API.

The merge window can be expected to run through approximately November 7. The latter part of the merge window will be summarized here in the November 10 Weekly Edition.

Comments (3 posted)

A btrfs update at LinuxCon Europe

Chris started by talking about btrfs and its goals in general; those have been well covered here and need not be repeated now. He reiterated Oracle's plan to use btrfs as the core filesystem for its RHEL-derivative Linux distribution; needless to say, supporting that role requires a rock-solid implementation. So a lot of work has been going into extensive testing of the filesystem and fixing bugs.

The 3.2 kernel release will see the results of that work; it will contain lots of fixes. There will also be significant improvements to the logging code. It turns out that a lot of data was being logged more than once, greatly increasing the amount of I/O required; that has now been fixed. I/O traffic for the log, it seems, has been cut to about 25% of its previous level.

For 3.3, the main improvement seems to be the use of larger blocks for nodes in the filesystem B-tree. Larger blocks can hold more data, of course, and, in particular, more metadata. That means that metadata that was previously scattered in the filesystem can be kept together with the relevant inode. That, in turn, leads to significant performance improvements for many filesystem operations.

Another near-term feature, due to arrive "right after fsck," is the merging of Dave Woodhouse's RAID5 and RAID6 implementations. That work was initially posted in 2009; Chris apologized for taking so long to get it merged. How this feature will actually be used still needs some thought; RAID5 or 6 is quite good for data, but it can be problematic for metadata, which tends to not fill anything close to a full RAID stripe and, thus, can lead to low I/O performance. Happily, btrfs has been designed from the beginning to keep data and metadata separate; that means that things can be set up where data is protected with full RAID while metadata is managed using simple mirroring.

Talk of protecting metadata leads naturally to the problem of recovering a filesystem when its metadata has been corrupted. That is what a filesystem checker program is for; btrfs, thus far, has been increasingly famous for it lack of a proper checker (and, more importantly, a proper filesystem repair tool). As of the LinuxCon talk, btrfs still does not have a real repair tool, but some progress has been made in that direction and a couple of other mechanisms have been provided.

The copy-on-write nature of btrfs implies that there will be numerous old copies of the filesystem metadata on the storage device at any given time. Any change, after all, will create a new copy, leaving the previous version in place until the block is reused. Chris observed that filesystem corruptions rarely affect that older metadata, so it makes sense to use it as a primary resource in the recovery of a corrupted disk. But, first, one needs to be able to find that older metadata.

To that end, btrfs maintains an array containing the block locations of many older versions of the filesystem root. The root block, he said, is more important than the superblock when it comes to recovering data. The root is replaced often as metadata changes percolate up to the top of the directory hierarchy, so the "old root blocks" array contains pointers to what is, in effect, a set of snapshots of the very recent state of the filesystem. Clearly, this will be a valuable resource should something go badly wrong.

One way of using that array is simply to mount the filesystem using an older version of the root. Chris demonstrated this feature by poking holes in a test filesystem, then mounting an older root to get back to where things had been before. For simple, quickly-detected problems, older root blocks should be a path toward a quick solution.

It is not too hard to imagine situations where this approach will not work, though. If a metadata block in a rarely-changed subtree is, say, zeroed by a hardware malfunction, it could go undetected for some time. By the time the user realizes that something is wrong, there may be no older hierarchy containing the information needed to put things back together. So other solutions will be necessary.

Obviously, one of those solutions will be the full filesystem checker and repair tool. That tool is still not ready, though. Getting a repair tool right is a hard problem; without a lot of care, a well-intentioned attempt to repair a filesystem can easily make it worse. Data that may have been recoverable before the repair attempt may no longer be so afterward. Even if a proper btrfsck were available today, it would probably be some years before it reflected enough experience to inspire confidence in users who are concerned about their data.

So it seems that something else is required. That "something else" turns out to be a data recovery tool written by Josef Bacik. This tool has a simple (to explain) job: dig through a corrupted filesystem in read-only mode and extract as much of the data as possible. Since it makes no changes, it cannot make things worse; it seems like a worthwhile tool to have around even if a full repair tool existed.

That tool, along with all the requisite filesystem support, is expected to be available in the 3.2 kernel time frame. Meanwhile, there is a new btrfs-progs repository that will include the recovery tool in the near future. All told, it may not be quite the btrfsck that some users were hoping for, but it should be enough to make those users feel a bit more confident about entrusting their data to a new filesystem. Judging from the size of the crowd at Chris's talk, there are a lot of people interested in doing exactly that.

[Your editor would like to thank the Linux Foundation for funding his travel to LinuxCon Europe.]

Comments (10 posted)

Frontswap gets broadsided

The core idea behind frontswap is to provide a less expensive alternative to pushing a page out to the swap device. That alternative could be one of a number of possibilities: storing the page (possibly compressed) in a memory pool shared between virtual machines, writing it to an SSD-based intermediate device, or adding a reference to a stored page with duplicate contents, for example. Frontswap is not required to accept a page handed to it, but, if it does accept that page, it must be able to reproduce it on demand in the future. The primary use case appears to be balancing memory use between Xen-based virtual machines, but others can be imagined.

If one were to look at the initial response to the post, it would appear that there was a groundswell of support for these patches; several messages came in calling for their inclusion. Those messages, however, came from other people at Oracle (Dan's employer) or other large companies, though, and their authors are not normally known for their participation in conversations about memory management code, so they may have had something other than the intended effect. It looked a bit like an organized pressure campaign. When the core kernel developers started to respond, the tone of the conversation changed considerably.

There were a number of complaints raised. The frontswap patches were not going through the -mm tree, and they did not carry acks from any of the recognized memory management developers, so some people started to suspect that Dan was trying to circumvent the normal processes. There is also a fair amount of doubt about the utility of the patches and the way they operate; Christoph Hellwig, for example, described frontswap as "a bunch of really ugly hooks over core code, without a clear definition of how they work or a killer use case." Various core memory management developers, their attention drawn by the pull request, found a number of things not to like.

One other complaint raised was the lack of any sort of associated benchmarks. Frontswap is, in the end, a sort of performance-enhancing patch; such changes are normally expected to be accompanied by test results showing that performance is indeed enhanced for the target workloads. Equally important is showing that performance is not hurt on other workloads - always a big concern when making changes to memory management behavior. For this kind of change, it is important to show that there is no impact on systems where the new facility is not used at all; Dan has not yet done that.

Chances are good that satisfying benchmark results can be produced eventually, and that the technical objections that have been raised can be fixed. Even then, though, frontswap is unlikely to get an immediate green light for merging into the mainline, for a few reasons. One is that life is never easy for those making core memory management changes; experience has shown that it is far too easy to make mistakes that only show up many months later when somebody tries their important workload on a new kernel. Dan has complained about the "hazing" he has gone through, but he has had an easier time than some others.

That said, Dan's life has not been improved by the association of his work with Xen which, while being free software that is now mostly in the mainline, is still looked upon dimly by many developers. His interaction style also sometimes does not help. Finally, Dan has, by virtue of unfortunate timing that is not at all his fault, run into another problem that was best explained by Andrew Morton:

Dan had not explicitly volunteered for that role, but, then, few people (or dummies) ever do. But, at this point, the process will have to play out on those terms. Barring some sort of surprising executive decision by Linus, this particular discussion is unlikely to come to a resolution before the close of the 3.2 merge window.

Another idea discussed at the kernel summit was that code that is in active use, and that is shipped by distributors over the long haul, should probably find its way into the mainline eventually even if it is not entirely pleasing. Transcendent memory has been in the openSUSE kernel since 2009, and has been shipped by Oracle for some time as well. Clearly, some people see value in this work. Given time, patience, and a willingness to address technical issues, that should be sufficient to get this capability into the mainline eventually.

Comments (3 posted)

Patches and updates

Kernel trees

• Deepak Saxena: Linaro Kernel October 2011 Release . (October 31, 2011)

Core kernel code

• Stanislav Kinsbursky: [PATCH v7 0/7] SUNRPC: make rpcbind clients allocated and destroyed dynamically . (October 28, 2011)

• Stanislav Kinsbursky: SUNRPC: initial part of making pipefs work in net ns . (October 31, 2011)

• Deepthi Dharwar: [PATCH v9 0/4] cpuidle: Global registration of idle states with per-cpu statistics . (October 31, 2011)

• Glauber Costa: per-cgroup /proc/stat . (November 1, 2011)

• Tejun Heo: cgroup: stable threadgroup during attach & subsys methods consolidation . (November 2, 2011)

Development tools

• Steven Rostedt: [GIT PULL] ktest: lots of nice new features . (October 31, 2011)

• Dmitry Monakhov: xfstests: Bunch of new stress tests -v3 . (October 31, 2011)

Device drivers

• Barry Song: dmaengine: add CSR SiRFprimaII DMAC driver . (October 28, 2011)

• Rajendra Nayak: Device tree support for regulators . (October 31, 2011)

• Rob Herring: net: add calxeda xgmac ethernet driver . (October 31, 2011)

• Manjunath Hadli: RFC for Media Controller capture driver for DM365 . (October 31, 2011)

• Sylwester Nawrocki: Staging: Abilis Systems AS102 driver . (October 31, 2011)

• Konrad Rzeszutek Wilk: TTM DMA pool v2.2 or [GIT PULL] (stable/ttm.dma_pool.v2.3) for 3.3 . (November 1, 2011)

• Ricardo Ribalda Delgado: Add spi support for CMA3000 driver . (November 2, 2011)

• Lin Ming: ata port runtime power management support . (November 2, 2011)

Filesystems and block I/O

• Pavel Shilovsky: SMB2 protocol support for CIFS kernel module . (October 31, 2011)

• Aditya Kali: Metadata Replication for Ext4 . (October 31, 2011)

• NeilBrown: hot-replace support for RAID4/5/6 . (October 31, 2011)

• NeilBrown: hot-replace support for RAID1 and RAID10 . (November 2, 2011)

• Zhu Yanhai: A readahead complete notify approach to implement buffer aio . (November 1, 2011)

Memory management

• Dan Magenheimer: mm: frontswap (for 3.2 window) . (October 31, 2011)

Networking

• Jiri Pirko: net: introduce ethernet teaming device . (October 31, 2011)

• Neil Horman: Introduce FCLONE_SCRATCH skbs to reduce stack memory useage and napi jitter . (October 31, 2011)

Architecture-specific

• Marek Szyprowski: ARM: DMA-mapping framework redesign . (October 31, 2011)

• Mahesh J Salgaonkar: [RFC PATCH v3 00/10] fadump: Firmware-assisted dump support for Powerpc. . (November 1, 2011)

• Omar Ramirez Luna: OMAP: iommu: hwmod support and runtime PM . (November 1, 2011)

• Peter De Schrijver: Add support for tegra30 and cardhu . (November 2, 2011)

• David Brown: msm: msm8660 and msm8960 clock support . (November 2, 2011)

Security-related

• Kees Cook: security: Yama LSM . (October 28, 2011)

Miscellaneous

• Anup Patel: (offtopic) Xvisor: eXtensible Versatile hypervISOR . (October 28, 2011)

Page editor: Jonathan Corbet

Distributions

Ubuntu focuses on mobile devices

As has become traditional, Mark Shuttleworth kicked off the Ubuntu Developer Summit (UDS) with a keynote (video link) looking back at the last release cycle and looking ahead to the next release. Following the keynote, Shuttleworth jumped on a conference call to share his vision for Ubuntu's next release and beyond. The long story short? Expect more of an emphasis on mobile and cloud, and less on the legacy desktop.

Canonical and the rest of the Ubuntu project is now starting the development cycle for Ubuntu 12.04, which will be a Long Term Support (LTS) release. This time around, Canonical is planning to do a five-year cycle for the client and server release. Shuttleworth said that this is in response from customers who have large Ubuntu deployments, though he didn't specify which ones.

Shuttleworth said that 12.04 will "draw to conclusion" the "threads" that started since the last LTS release. For example, solidifying the Unity desktop and work on the cloud services in Ubuntu. At the same time, Shuttleworth is already looking forward to the 14.04 LTS and putting Ubuntu on tablets, phones, televisions, and other mobile and embedded devices. Ubuntu has been focusing on touch interfaces for some time, but now Shuttleworth said that Ubuntu "is in a position" to span "from phone to televisions, to car, and elsewhere."

That's quite an ambitious perspective, especially considering two things. First, Ubuntu is a little bit late to the game. Giants like Microsoft, Google, and Apple have already been jockeying for position for years. Android and iOS have already carved out a pretty enormous swath of the tablet and phone markets, and word around the campfire is that Apple is poised to release a TV in the not-too-distant future. By the time Ubuntu 14.04 rolls around, or even 13.04 with preview technology for mobile, other companies will be well into their Nth generation of technology in markets Canonical will just be dipping a toe into.

The second is that Canonical is a really tiny David in this David and Goliath story. On one side, Canonical faces the aforementioned industry giants. On the other hand, Canonical is also competing with industry consortia like Tizen.

Essentially, Canonical seems to be facing an uphill battle similar to that the company faced when it attempted to take on the desktop against Microsoft and Apple. Currently, Shuttleworth boasts 20 million users for Ubuntu. Leaving aside the fact that Canonical doesn't actually publish the information used to gather those numbers, 20 million users have not been enough to qualify as mainstream success on the desktop. Now the company is planning to enter markets where it's completely unknown and years late.

So I asked Shuttleworth why he thinks that Canonical will be poised to compete here? First, he acknowledged that Ubuntu would be late to market. However, he said that this market is a bit different. First, it's a highly contested market with no clear winner. Shuttleworth said that there is the potential for "dramatic shifts" in the market, and that has been the case in the past with the arrival of Android. He also said that there's potential backlash to Google picking up Motorola Mobility. The "Googlerola" deal might change the way that companies feel about Android, Shuttleworth said — which provides an opening to Canonical.

Tizen will not satisfy the need, Shuttleworth said, because consortia have "an inability to deliver a focused, concrete" solution. This point is rather hard to argue, given the string of failures (i.e. Moblin, Maemo, MeeGo) thus far. So Shuttleworth said vendors "have me on the phone to ask how quickly we can bring a mobile story with Ubuntu." Canonical has declined to identify particular vendors until there are products ready to go to market. That may take a while; if not as late as 2014 certainly not in 2011 and likely not in 2012.

Without products to hack on, how will developers be testing their applications, assuming interested developers want to get the next Angry Birds (or the current one) put together for Ubuntu on mobile? Shuttleworth said that in the interim Ubuntu will target existing hardware that ship with different OSes. "We'll target existing hardware that's available around the world, cheaply."

Developers can use HTML5 or QML to target Ubuntu for mobile, said Shuttleworth. For multi-platform, low-resource applications, HTML5 should be fine, he said, and Canonical will "make sure that HTML5 apps work beautifully on all devices." For games and native applications, Shuttleworth said that developers can have a "smoother" experience targeting Ubuntu using QML.

One key criticism of tablets, in particular, from the open source community is that they're essentially for consuming media — not for creating content or hacking. I asked Shuttleworth if Canonical had any plans to address this with Ubuntu's tablet releases. Unfortunately, Shuttleworth said that the 1.0 release will also be primarily focused on standard tablet behavior (consuming content), but of course an Ubuntu tablet will have a wide range of applications.

One potential snag is how Canonical is going to turn a profit on its mobile work when any vendor could just pick up Ubuntu and put it on its own devices without Canonical's blessing. Shuttleworth said that Android has shown that path to be "ultimately destructive" when vendors choose to go their own way. He didn't explain this in detail, but there are few Android success stories from vendors that are not partnered with Google. The notable exceptions are Barnes & Noble, which seems to be doing quite well with the Android-based Color Nook, and Amazon. While Amazon hasn't yet shipped the Android-based Kindle Fire, it seems to have been well received initially. Nevertheless, Shuttleworth said he's "confident" that many of the ISVs will want an engagement with Canonical for services, which will be one revenue stream.

The Ubuntu One framework and its services will provide another income stream, he said. Shuttleworth envisions devices shipping with Ubuntu and Ubuntu One services, which Canonical will generate revenue from. This may wind up being successful — during the UDS keynote, Shuttleworth mentioned that of 110,000 new users to Ubuntu One, 25,000 had never used Ubuntu before.

For the next Ubuntu release, then, expect the feature set to be fairly conservative. Canonical will be focusing on polishing Unity and improving the integration of OpenStack and the new cloud management software (Juju) that was introduced with 11.10. Unfortunately, this topic was not really discussed during the press call with Shuttleworth and my attempt to connect with the right person at Canonical on server plans was hampered by the ongoing UDS.

Shuttleworth and Canonical are taking on a steep challenge with the play for phones, tablets, and other devices. It's interesting that Shuttleworth spent little time talking up Ubuntu's strategy as an operating system of choice for cloud infrastructure, especially given the work that the Ubuntu folks put into Ubuntu's cloud tools in the 11.10 release. Perhaps Canonical has learned enough from attempts at desktop success to make a go on the next wave of devices for personal computing. It will certainly be interesting to watch.

Comments (19 posted)

Brief items

Distribution quote of the week

Comments (3 posted)

OpenBSD 5.0

Comments (7 posted)

Announcing OLPC OS 11.3.0 for XO-1, XO-1.5 and XO-1.75

Full Story (comments: none)

End of support for Ubuntu 10.04 Netbook and ARM

Full Story (comments: none)

Distribution News

Debian GNU/Linux

Bits from the New Maintainer^WMember process

Full Story (comments: none)

openSUSE

openSUSE Board Election 2011

Comments (none posted)

Newsletters and articles of interest

Distribution newsletters

• DistroWatch Weekly, Issue 429 (October 31)
• Fedora Weekly News Issue 287 (October 26)
• Maemo Weekly News (October 31)
• openSUSE Weekly News (October 29)
• Ubuntu Weekly Newsletter, Issue 239 (October 30)

Comments (none posted)

Fedora 16 is Coming With Big Changes (Linux.com)

Comments (51 posted)

Shuttleworth: Linux Power Users Aren't too Cool for Unity (Datamation)

Comments (82 posted)

Shuttleworth: Ubuntu on phones, tablets, TV's and smart screens everywhere

Comments (13 posted)

Page editor: Rebecca Sobol

Development

ELCE11: Sandboxing for automotive Linux

On the second day of the Embedded Linux Conference Europe (ELCE), Iisko Lappalainen from MontaVista Software presented a method for running secondary Linux environments inside a "host" Linux OS with strict sandboxing and security requirements. The example use-case was running Android inside a GENIVI-based Linux in-vehicle infotainment (IVI) system, though other combinations are possible. The setup would permit a car-maker to ship a system with full access to an Android application ecosystem, while maintaining isolation from the underlying OS.

As GENIVI's Matt Jones explained in an earlier session, the GENIVI middleware stack is isolated from the vehicle's safety-critical systems like engine control and anti-lock braking; running on separate hardware on electrically isolated circuits. But there are still important functions in an IVI system that, if interrupted, would greatly inconvenience the user. Navigation on the head unit, or proximity sensors on the bumpers, for example — neither one should hang or crash just because a child in the back is playing a buggy video game on a rear-seat entertainment screen. Buggy games aside, there is also always the prospect of intentionally malicious code.

That provides one use-case for running applications inside some sort of sandboxed environment. Lappalainen listed several others. First, it would provide a way to run applications written for multiple UI frameworks, in particular, frameworks not natively supported by the base IVI system. The example he presented was an HTML5-based web runtime, which was not a component planned for the MeeGo IVI user experience (UX), which GENIVI designated in 2010 as its reference platform. Canonical has subsequently announced its own GENIVI-compliant IVI remix, which also does not address a web runtime; MeeGo's successor Tizen, however, does have a web runtime.

The Android environment in particular offers its own advantages as the sandboxed OS, Lappalainen said. The existing ecosystem is enormous, both in terms of applications and trained developers. Android's "app store" model also explicitly supports multiple, branded app stores, which would allow OEMs to provide their own software product channel directly in the IVI system. Finally, if done right, sandboxing should allow the OEM to enforce a tight security model on the applications inside — perhaps providing a more isolated environment for untrusted, user-installed applications, while factory-installed applications are allowed to run natively.

The containerized approach

The sandboxing approach taken by MontaVista utilizes Linux Containers (LXC) to isolate the sandboxed environment, and SELinux to supply a security layer. LXC containers provide a form of virtualization by isolating the sandboxed processes in a separate control group — thus allowing the host OS to limit resource usage and isolate file access — and by maintaining separate process ID and network namespaces. Separate namespaces not only hide the host OS from each container, but isolate each container from the others.

Lappalainen referred to this approach as "virtualization," but that term can mean different things to different people. Specifically, LXC containers provide OS-level virtualization akin to OpenVZ or Virtuozzo. A system running inside an LXC container can have its own view of the filesystem and a separate group of processes — with entirely different user-space code — but it still uses the same kernel as the "host" (for lack of a better term) OS. This is a distinct difference from hardware-level virtualization, which supports running any flavor of guest OS on top of the host OS. On the other hand, OS-level virtualization is generally faster because there is no overhead associated with running a virtual machine layer.

But OS-level virtualization also introduces a hurdle to running one Linux-based OS inside of another if the two OSes differ significantly in kernel features, not just userspace. That is certainly the case with Android, which replaces several stock kernel features and adds several other features. In MontaVista's Android-on-GENIVI project, the host kernel is patched with Android-specific features.

Lappalainen listed the Android kernel's IPC binder, low-memory killer, logger device, and asynchronous shared-memory system (ashmem) in particular on his slides; in the talk however he simply described the kernel as including the "Android patches." He also mentioned that these kernel functions needed to be adapted to work only within the context of the Android container. In particular, Android replaces the standard Linux out-of-memory (OOM) killer with its own variety. One would only want the low-memory killer to watch for low memory conditions within the Android container, and then to only kill one of the Android container's processes.

The guest-OS containers are configured so that their processes run at lower priority than the host OS's. There are also various mechanisms used to process IO, graphics, and other resources for the collection of containers. The "event dispatcher" tracks the window coordinates of each application, for example, so it can route input events to the proper container or to the host OS. Graphics output is handled by capturing the Android container's frame buffer, and sending it to a "layer manager" that overlays it on the display together with video output from the other applications. Audio is less tricky to coordinate, he said, because it can be down-mixed into one output by the audio server. This is already what ALSA and PulseAudio do when multiple applications play sound simultaneously.

Power management is handled entirely by the host OS, which Lappalainen said required changes to the Android wakelock code. On multi-core systems, he added, the container-management code can also be used to bind containers to specific processors, which provides another method of ensuring that they cannot bring down the host OS even in the event of a serious fault.

Lappalainen did not go into much detail on the role that SELinux plays in providing further isolation for the LXC containers. It is certainly possible that SELinux could simply be set up to duplicate the filesystem isolation and other sandboxing mechanisms provided by LXC, acting as a separate, back-up "wrapper" around the containers. But SELinux might also plug security holes in LXC. For example, LXC does not provide user namespaces, which means that a malicious root user could escape from its container and execute code as the root user on the host OS.

Code and product

Lappalainen outlined various use-cases for the LXC/SELinux containerization approach, noting that it could also be beneficial in other embedded Linux projects because it can isolate untrusted applications, but without the performance hit of running them in an emulator. MontaVista's implementation of this configuration is its Automotive Technology Platform (ATP), a commercial IVI product.

The company announced ATP's Android-and-HTML5 support feature in an October 10 press release, which positions ATP as a competitor to open projects like MeeGo/Tizen and Ubuntu IVI — in particular, one that has a leg up on the competition thanks to the vast array of already-written Android and HTML5 applications. IVI was not a major topic at ELCE; Jones' talk was the only other session dedicated to IVI, and it dealt as much with the plans and in-house experiments of his employer Jaguar Land Rover (JLR) as it did with GENIVI.

An illuminating snippet from that talk, however, was that it will be 2014 at the earliest before any Linux-based IVI systems are available in JLR vehicles. That is an exceptionally long time in kernel and distribution time-scales. A few other car-makers are reported to be closer, notably BMW, but have not announced a deployment schedule.

In fact, ever since the announcement of the MeeGo IVI platform, it seems that the IVI software industry has changed drastically faster than the car industry with which the rival platforms are vying to go into business. There were rumors that GM would adopt Android as the next-generation base for its OnStar system, only to have the company join GENIVI instead. MeeGo brought on several major car-makers as partners (including Toyota) in early 2011, then MeeGo morphed into Tizen without warning.

That much change can make it difficult to handicap the players. However, the big obstacle for ATP is likely to be asking car-makers to undertake supporting Android and a GENIVI Linux distribution. Even apart from the handset-and-tablet-centric stance that Google takes with the product, it sounds like a challenging customer support undertaking. In 2011, GENIVI quietly began shifting its language away from talk of a MeeGo "reference implementation" and towards "GENIVI compliance," which blesses multiple distributions. That could be because GENIVI had early warning of the migration from MeeGo to Tizen; regardless of whether or not GENIVI formally adopts Tizen as its reference platform, Tizen will match ATP's HTML5 support, which could make the web-runtime selling-point moot.

In short, though the work that has gone into virtualizing "guest" Linux OSes in MontaVista's ATP is interesting, it seems odd to position it as an IVI-specific technology. There are certainly plenty of users of other form factors that would love the chance to run thousands of Android applications inside a secure sandbox — starting with smartphone and desktop Linux distributions. Whether ATP, Android itself, or some other solution entirely is adopted by GENIVI or the car-makers remains to be seen, but it does seem likely that a hybrid like ATP will be fighting an uphill battle.

[The author would like to thank the Linux Foundation for assisting with his travel to the Embedded Linux Conference Europe 2011.]

Comments (8 posted)

Brief items

Quotes of the week

Comments (6 posted)

ALAC codec now open source

Comments (30 posted)

GNOME 3.3.1 Development Release

Full Story (comments: none)

GParted 0.10.0

Full Story (comments: none)

libabc: a demonstration library for kernel developers

Comments (83 posted)

Mercurial 2.0 released

Full Story (comments: 16)

Tahoe-LAFS 1.9 released

Full Story (comments: none)

Transmageddon 0.20

Full Story (comments: none)

Xvisor 0.1.0

Full Story (comments: 3)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (November 1)
• GCC 4.7.0 status report (October 27)
• LibreOffice development summary (October 31)
• Open Hardware Journal (November 1)
• Perl Weekly (October 31)
• PostgreSQL Weekly News (October 30)

Comments (none posted)

Hoogland: Q&A with Enlightenment Lead Developer "Rasterman"

Comments (8 posted)

KDE 4: Leader of the Semantic Pack (Linux.com)

Comments (54 posted)

Page editor: Jonathan Corbet

Announcements

Brief items

Two UEFI secure boot white papers

UEFI Secure Boot Impact on Linux [PDF], published by Red Hat and Canonical, was written by Jeremy Kerr, Matthew Garrett, and James Bottomley. "We present a set of recommendations that will allow users the freedom to choose their software, while retaining the security features of UEFI Secure Boot, and complying with open source licenses used in distributions of Linux."

Comments (13 posted)

Proceedings from the 13th Real Time Linux Workshop

Comments (8 posted)

@openoffice.org email forwards may be shut down soon

Full Story (comments: none)

Document Foundation Board 2011: Final Results

Full Story (comments: none)

Articles of interest

Intel's Dirk Hohndel on 20 Years of Linux (Linux.com)

Comments (4 posted)

Upcoming Events

DebConf12 Nicaragua dates confirmed

Full Story (comments: none)

Events: November 10, 2011 to January 9, 2012

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

Page editor: Rebecca Sobol