LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DevelopmentLCA: Chrome OS and open firmwareAt linux.conf.au, Google's Duncan Laurie presented a talk (slides) about the company's recent work writing open source firmware for its Chrome OS-based laptops. Although there are still some instances of closed firmware on the current crop of Chrome OS devices, the project is clearly making progress on that front—with potential benefits for other free software systems as well. Laurie, who outlined his previous work on open source firmware projects at Cobalt Networks and Sun, started off by emphasizing that Chrome OS is not a general-purpose operating system. Instead, it is targeted at specific devices, over which Google has control—although, he added, there are people who have built Chromium OS (the open source version of Chrome OS, analogous to the Chromium browser) distributions for other hardware. Google's control over the devices means imposing requirements on the hardware supplier that other Linux distributions generally do not mandate, including support for security features like Chrome OS's verified boot process and inclusion of a Trusted Platform Module (TPM). But as long as the company is dictating to the hardware supplier, he said, it thought it would be interesting to see if it could be disruptive and open up parts of the firmware payload that are usually closed. The first two generations of Chrome OS devices shipped with an EFI firmware stack that Google licensed from an existing firmware vendor. But Google has no freedom to release any of that code under an open source license, including the code it wrote to integrate its security features. Opening up the firmware code offers several advantages to the company, including the ability to devote more resources to the firmware project if the project is in danger of missing its ship date, as well as simply having more eyes scrutinize the code. Developing firmware includes tackling a number of hard problems on modern Intel and ARM systems, he said, and working on it regularly uncovers new bugs, from the hardware level on up. Controlling the firmware also gives Google the opportunity to deliver consistency across multiple architectures, and to work on reducing power consumption and increasing performance. BIOS and bootingLaurie then provided a detailed tour through the Chrome OS firmware stack, highlighting which pieces are open, which are not but could become open, and which have no real chance of ever being opened. His talk focused on the x86 architecture, because it is the platform he and the project as a whole have spent the most time on. At the core of the firmware stack is coreboot, the open source BIOS replacement. Both coreboot's founder and its current maintainer both work on the Chrome OS firmware team, a fact that Laurie said made coreboot "a pretty easy choice for us." Coreboot's overall structure is quite similar to EFI, he said, since these days there are a fairly well-established set of stages involved in getting a system up and running. One key difference is that coreboot does not include a bootloader; it has a more general "payload" instead, which allows you more flexibility in what to do when bringing up the board. Other interesting differences include the fact that coreboot's first stage ("bootblock") is written partly in assembly, but partly in C that is compiled with romcc, a special compiler that uses only processor registers for variable storage. Chrome OS uses the U-Boot bootloader as its coreboot payload. This is a bit unusual for x86, he said, since U-Boot is mostly commonly known as an ARM bootloader, but the project chose it because Google had already done the work to integrate its verified boot process into U-Boot. Nevertheless, U-Boot is a bit more complicated than Chrome OS really requires, so the project is keeping the door open to other bootloaders in future releases. Closed bits and open bitsCoreboot also executes some closed-source binaries, the first of which is the Intel reference code binary required to get memory up and running. This code is provided by Intel to licensed BIOS vendors. It is normally supplied as an EFI module, Laurie said, but Chrome OS wrote wrappers around it to enable its use by coreboot. The project has put binary blobs of those packages on coreboot.org for Sandy Bridge and Ivy Bridge, but the distribution terms prevent them for doing so for other generations of hardware. Google has been working with Intel to find a way for the chip vendor to distribute these newer coreboot binaries, however. The effort is called the Intel Firmware Support Package, and is documented online. Another blob of closed code provided by Intel is the firmware for the Management Engine, a microcontroller handling various features like clock signal generation. Laurie said the Management Engine makes life more difficult for Chrome OS, since it is quite large (from 1.5 to 5 MB) and difficult to configure and debug. Configuration of the blob is mandatory, and can only be done with an application Intel provides for Windows machines only. Chrome OS does not normally need to initialize video hardware, since the Intel i915 graphics driver in the Linux kernel can bring up and initialize graphics on its own. However, Chrome OS does need video capabilities for recovery mode and developer mode, so the project currently includes the Intel-provided binary blob for this purpose. But it is exploring another option: extracting the initialization code from the kernel driver to use separately. The Embedded Controller (EC) is another microcontroller found in virtually all notebooks, and which is responsible for a variety of platform tasks like fan control, battery charging (which, after all, must work even when the computer is powered down), and lid and power-button control. On x86, the EC usually has both a firmware interface and an ACPI interface. Laurie described the EC as the component "closest to his heart;" the project wrote its own EC code after failing to design hardware that would work without an embedded controller at all. The code is open, and is now shipping in the Samsung ARM Chromebook. EC firmware is a tempting (if largely unknown) security target, he said, so Chrome OS has incorporated it into its verified boot process. Firmware featuresSpeaking of verified boot, Laurie explained that the feature has a similar design to UEFI Secure Boot, but that its "root of trust" is read-only firmware. To replace this read-only firmware requires physical access to the machine, but Google provided documentation on how to do this for all Chrome OS products. In operation, the read-only firmware verifies the signature of the updatable "read-write" firmware, which in turns verifies the signature of the kernel. The read-only portion of the firmware contains the initial coreboot stages and U-Boot; the read-write firmware would contain any updates and fixes, but is primarily used to verify and boot the kernel. Chrome OS also includes a "recovery mode" that can be used to restore a system that has been compromised: recovery mode is stored in read-only firmware and will only boot a signed image from a USB stick, not from the local disk. Recovery mode can be triggered if the verified boot process detects a compromise, or can be initiated by the user (on current Chromebooks, via a hardware switch which ensures the user is physically present). Similar methods allow the user to access "developer mode," which is a jailbreak mode built into every Chromebook device. "Chrome OS is very locked down by default, but we really don't want to lock people out from doing interesting things with the hardware they own." Chrome OS firmware also features a persistent log of system events—because, as Laurie explained, firmware is often the first place people point fingers when they encounter a bug. The log is based on the SMBIOS System Event log, but it has a kernel sysfs interface as well—which makes it possible to debug some kernel problems through the firmware log. The firmware also saves all console output generated during the boot process to a memory buffer, which is then exported at /sys/firmware/log. Laurie provided a brief overview of the ARM boot process as it differs from the x86 equivalent. Although the vendor-provided binaries appear in different places, they are present on the ARM devices as well. Nevertheless, the boot process is quite similar, ending up with U-Boot booting the signature-verified kernel. Ultimately, he concluded, it is important to have as much open firmware as possible, since the different layers interact so much even in seemingly simple scenarios. For example, opening a laptop lid cycles through a number of policy decisions (such as whether the user is logged in or not) and hardware events (such as laptop lid switch signals, routed through the Embedded Controller and relayed to the kernel through ACPI events). Most free software fans would likely agree with Laurie's sentiment, although the full inventory of firmware modules involved on a modern PC might come as a surprise to some.
Brief items Quotes of the week
Normal versioning problems that we just take for granted in C,
such as allowing the coexistence of two versions of the same
library with different ABIs on the system at the same time without
doing the equivalent of static linking, vary between ridiculously
difficult and completely impossible in every other programming
language that I'm aware of (with the partial exception of C++
where it is possible to use the same facilities as C, just
considerably more difficult).
— Russ Allbery
In fact, most new languages seem to be *regressing* here. Both Perl and Python were already fairly bad at this, Java bailed on the problem and shoved it under the carpet of a version of static linking, and now Go is even worse than they are and is explicitly embracing static linking. Sigh.
But still, it's hard not to be frustrated when it feels like
people with a significant interest in the future of Perl 5-like
languages are told that all future version numbers belong to a
project that has significantly fewer users, developers, and
mindshare than the existing Perl 5 language (and community).
— Dave Rolsky
Yet another grand plan for the architecture is no better
than what we have, if it isn't executed. This isn't an academic
exercise, we don't get points for thinking about cool things.
— Allison Randal
LibreOffice 4.0 releasedThe Document Foundation has announced the release of version 4.0 of the LibreOffice free office suite. As might be guessed, there is a whole pile of new features in the release, including content and document management system integration, better DOCX support, performance improvements, Android-based remote control for Impress, and more. There has also been a great deal of change to the code base: "The resulting code base is rather different from the original one, as several million lines of code have been added and removed, by adding new features, solving bugs and regressions, adopting state of the art C++ constructs, replacing tools, getting rid of deprecated methods and obsoleted libraries, and translating twenty five thousand lines of comments from German to English. All of this makes the code easier to understand and more rewarding to be involved with for the stream of new members of our community."
NumPy 1.7.0 availableVersion 1.7.0 of the NumPy library is now available. This release includes a random sample generator, improvements to vectorize, and a where parameter for ufuncs, which "allows the use of boolean arrays to choose where a computation should be done."
New release of xrandr, version 1.4.0Aaron Plattner has announced the availability of xrandr 1.4.0. This is the command line tool for accessing the X11 Resize, Rotate, and Reflect (RandR) extension. New features include support for RandR 1.4's provider objects, new scaling options, and the ability to use the Border property to "configure different border adjustments for different edges of the screen."
ODB C++ ORM 2.2.0 releasedA major new release of ODB 2.2.0, the object-relational mapping (ORM) system for C++, is available. This version features several new features, starting with the ability to connect to multiple database systems from the same application. Other features include Qt5 support, automatically-derived SQL name transformations, and "prepared queries," which are described as "a thin wrapper around the underlying database system's prepared statements functionality. Prepared queries provide a way to perform potentially expensive query preparation tasks only once and then execute the query multiple times."
SystemTap release 2.1Version 2.1 of the system diagnostic tool SystemTap has been released. Highlights include customizable aggregate array sorting, optional time limit suppression, and experimental compiled regex support. Emacs and Vim editor modes for SystemTap are now bundled as well.
Newsletters and articles Development newsletters from the past week
Gräßlin: Client Side Window Decorations and WaylandKWin hacker Martin Gräßlin discusses client side decorations (CSD) and Wayland on his blog. He notes that while Weston—the reference Wayland compositor—requires CSD, nothing in the Wayland protocol does. "I had a talk with Andy from Qt Wayland fame about the CSD implementation and he explained [to] me that inside Qt the CSD code gives some overhead and that they have a flag to turn them off. Which is great. And we in KWin already have server side decorations and will need to keep them around for legacy X applications. What's the point then to use CSD in Qt if we already have the decorations and can give the application a better performance? Well none and that's why I plan to use server side decoration in KWin on Wayland."
OpenPlans: EveryBlock and OpenBlock (and something new)The OpenPlans blog reports on the abrupt shutdown of EveryBlock, a popular "hyperlocal" news site run by NBC (and which was initially based on open source code). "What we lost today was a powerful (closed) engine for gathering data from many different sources and making sense of it," OpenPlans says, adding that it hopes the EveryBlock shutdown will reignite interest in the open source fork of the original codebase, OpenBlock. Others have commented on the sudden shutdown as well, including Mozilla OpenNews, which said the site "exemplified new approaches" to journalism.
Chromatic: Goodnight, ParrotPerl developer Chromatic has posted a post-mortem of sorts for the Parrot virtual machine. "Because volunteer time and interest and skills are not fungible, some of the people working Parrot had goals very different from mine. I wanted a useful and usable Perl 6 which allowed me to use (for example) PyGame and NLTK from Python and (if it had existed at the time) a fast CSS traversal engine from a JavaScript implementation. Other people wanted other things which had nothing to do with Perl 6. I won't speak for anyone else, but I suspect that the combination of a deliberate distancing of Parrot from Perl 6, including separate repositories, the arm's length of a six month deprecation policy, and an attempt to broaden Parrot's focus beyond just Rakudo created rifts that have only widened by now."
Pitt: umockdev: record and mock hardware for debugging and testingMartin Pitt introduces umockdev, a device simulation library. "The umockdev-run program builds a sandbox using libumockdev, can load *.umockdev and *.ioctl files into it, and run a program in that sandbox. I. e. it is a CLI interface to libumockdev, which is useful in the 'debug a failure with a particular device' use case if you get the text dumps from a bug report."
LibreOffice 4.0: First Take (ZDNet)ZDNet reviews the LibreOffice 4.0 release. "The Document Foundation (the organization behind LibreOffice) calls version 4 a milestone release. It's hard to agree, though — unless the milestone is more like the starting line. On the surface this looks like a welcome point release that improves compatibility, although bringing the Android remote presentation control to Windows will make it more significant. However, after all this time we were hoping for a much more major update."
Page editor: Nathan Willis |
|||||||||||||