At 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
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 booting
Laurie 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
Closed bits and open bits
Coreboot 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
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
Speaking 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
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.
Comments (4 posted)
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).
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.
— Russ Allbery
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
Comments (3 posted)
The 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.
Full Story (comments: 67)
Version 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."
Full Story (comments: none)
Aaron 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."
Full Story (comments: none)
A 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
Full Story (comments: none)
Version 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.
Full Story (comments: none)
Newsletters and articles
Comments (none posted)
KWin 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.
Comments (103 posted)
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.
Comments (5 posted)
Perl 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
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.
Comments (158 posted)
Martin Pitt introduces
, 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.
Comments (1 posted)
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.
Comments (34 posted)
Page editor: Nathan Willis
Next page: Announcements>>