Google releases Chrome OS security update

US-CERT reports that Google has Released Security Updates for Chrome and Chrome OS

“Google has released security updates to address vulnerabilities in Chrome and Chrome OS. Exploitation of one of these vulnerabilities may allow a remote attacker to take control of an affected system. Updates available include:

  * Chrome 46.0.2490.86 for Windows, Mac and Linux
  * Chrome 46.0.2490.82 for all OS devices

Users and administrators are encouraged to review the Chrome page and Chrome OS page and apply the necessary updates.”

More Info:


Google to merge Android and ChromeOS?



Personally, I’d like to see Android Verified Boot and Chrome OS Verified Boot unified! 🙂



Libreboot ported to modern ARM Chromebook

Earlier this month, Paul Kocialkowski announced some work of his: getting Libreboot running on an ARM-based Chromebook, the Asus C201 “veyron_speedy”). Paul is a developer on the Replicant project, a free-as-in-freedom Android distribution.

Some quotes from Paul’s announcement:

“It should require no proprietary code nor any proprietary firmware load or microcode update to boot, thus it would be a good fit for Libreboot, as a fully free distribution of Coreboot.”

“At this point, I’ve been able to boot up Debian on the device, and the xfce4 interface is quite usable. It even runs big programs like Iceweasel/Firefox and LibreOffice without inconveniences.”

“Overall, I truly hope this device creates an incentive to free the last remaining parts that can only work with proprietary software to this day. Its potential would be huge, especially since it’s a good fit for travellers. With the security model inherited from Chromium OS, this would be one of the safest laptops to be used by journalists or activists. If Tails was to be ported to it, it would become easy to have a secure and anonymous setup.”

See the below libreboot mailing list post for full announcement. It’s not perfect, there are some issues with the Mali T764 Mali, and free software support, and some other rough edged, but perhaps these can be worked out over time.

Also, as mentioned in an earlier post, Paul will be at Chaos Communications Camp (CCCamp) 2015 later this week:

“I’ll be at CCCamp 2015 to talk about Replicant (as well as other things that I’m working on, like porting Libreboot to the C201 Chromebook), starting tomorrow.”

Very nice work Paul!!



What is the safest firmware solution?

Stephan of the coreboot project is currently having a Twitter conversation with some others. It includes this post:

This makes me wonder, has anyone compared Chrome’s Verified Boot with UEFI’s Secure Boot. With and w/o TPM chip on Intel or TrustZone on ARM. It would be nice if some cyypto-savvy researchers could analyze the crypto used in both implementations and give a comparison, including how these solutions meet the NIST and NSA/CC criteria for securing BIOS.

In terms of code size, coreboot has a much smaller codebase than tianocore, even with the all the additional size that Chrome brings to it’s coreboot dialect. But both Secure Boot and Verified Boot are nearly the same in terms of PKI.

On a related not, I’ll do a future blog post looking into the various boot flavors: Trusted Boot, Secure Boot, Measured Boot, Verified Boot, etc.


coreboot and Chrome OS upstreaming

I mainly work with UEFI technology, and don’t know much about coreboot, nor Chrome OS. I’m new to these tech, and learning them… 🙂

For a while, I thought coreboot was pretty inactive, but I now realize much of the coreboot activity has been taking place in Chrome OS. It appears that some of this work is now being upstreamed to the main coreboot.

From the coreboot blog:

“In the last months there was lots of activity in the coreboot repository due to upstreaming the work that was done in Chrome OS’ branch. We’re happy to announce that both code bases are again relatively close to each other. In the last 7 months, about 1500 commits that landed in coreboot originated in Chrome OS’ repository (of about 2600 total). Those came from 20 domains, which represent pretty much every part of the coreboot community: well known private and commercial coreboot contributors, but also BIOS and silicon developers as well as device manufacturers. Significant contributions that went into the tree recently were written with active support by Broadcom, Imagination Technologies, Intel, Marvell, Nvidia, Qualcomm, and RockChip.”

“In the future, Chrome OS will move over to a new branch point from upstream, and work on strategies to avoid diverging for two long years again. Instead, we’re looking for ways to keep the trees closer while also avoiding flooding the coreboot.org developer base with hundreds of patches. More on that as it is implemented.”

Some features that’ve been recently added include:
* new MIPS support
* improved ARM support, for SoCs by Broadcom, Marvell, Qualcomm, and RockChip
* an improved, safer method to declare the memory map on devices
* effort to get Chrome OS’ verified boot support
* update the flash image format to allow for safer incremental updates

This looks like great news for coreboot! I’ll have more blog entries about coreboot and Chrome OS in the near future.

More Information:


Comments on recent Reddit on UEFI and Linux

There’s a popular Reddit going on about UEFI and Linux:


which I noticed on Matthew Garrett’s blog, which also has some good insight on the topic:


The Reddit author is complaining to Intel and Microsoft about the bloat of UEFI compared to a minimal boot loader, and the need for Coreboot, and how Linux doesn’t need most of this bloat.

“Unfortunately this means that it’s extremely complicated and big. The firmware is now as big and complicated as a full-fledged OS.”

Actually, UEFI *is* an OS, not just a firmware/boot loader like Coreboot or BIOS. UEFI is a complex OS, with dozens of driver models. The original IBM PC had BIOS, and was useless without MS-DOS (or another OS). Modern UEFI-based systems have no need for BIOS, the UEFI driver models replace BIOS OptionROMs, and UEFI can be either an OS or a firmware loader, depending on how used. UEFI systems don’t need an additional OS — Windows, Linux, etc. — to be installed. The UEFI OS is about as useful as MS-DOS 2.0, a shell, about 80 commands, a handful (edit, hexedit) of full-screen ‘curses’-like. Tweaking the shell to run your embedded app, there’s no need for the bloat of an additional OS.

“Complicated and big is bad. This means more bugs. Some bugs are security bugs so more bugs means more security holes. Also it’s generally proprietary so you have different groups of people trying to write the same thing from scratch so they can inject their ‘secret sauce’. So now not only you have something that is big and buggy, but also has lots of different sets of unique bugs.”

“Also it allows for a lot of fancy new ways to manage your hardware independently of the OS. Which while often convenient it is also going to be full of bugs and is proprietary. Which is going to be especially bad when the UEFI stuff allows for remote configuration and will piggy back on your network interfaces and doesn’t go away completely when the real OS is loaded.”

Small is nice. Secure is also nice. Modern BIOS have to deal with NIST and NSA/IAD guidelines for secure BIOS, and how that drives some sales. ..which Microsoft uses well to get SecureBoot into most systems. Google has taken barebones Coreboot and made is much more complex, in the name of security, when adding SecureBoot-like PKI features in Chromium. Large servers are more complex w/r/t updating firmware, and have various ‘pre-OS’ apps (iLO, IPMI, etc.) all of which were designed for some business need (hopefully beyond merely to sell hardware), and IPMI is ripe with security issues. UEFI attempts to deal with this, I’m not sure how Coreboot deals with or ignores this reality.

UEFI is well-entrenched in the PC world, used by Apple and Microsoft and Intel, and Windows OEMs do whatever Microsoft says. I don’t see future with a non-UEFI solution for Intel-based Windows OEMs. An alternate route for Linux OS users may be to focus on Chrome OEMs, which use Coreboot. Or to focus on AMD systems, which also use Coreboot. Or to focus on ARM systems, which use either U-Boot or UEFI, the latter mostly for business reasons not technical reasons, AFAICT.

Linux OEMs could select Coreboot. Linux OEMs could build UEFI using Coreboot as it’s PI layer, reducing a bit of UEFI complexity with Coreboot. Linux OEMs could use UEFI properly, without MSFT CA or keys, using SecureBoot to secure Linux, without begging Microsoft for permission to secure non-Windows OSes on WindowsPCs — Intel and SuSE demonstrated this at IDF in 2013, yet I’ve not seen a single Linux consumer device made by OEMs for Linux users. Last time I talked to a Linux OEM, a few weeks ago, they liked UEFI, since SecureBoot scared their Linux-centric customers to legacy BIOS systems, and the OEM was too lazy to work with Sage Engineering to reduce the number of blobs in their code and add Coreboot support to their units. Linux OEMs are not that bright. Neither are Windows OEMs, but Microsoft tells them what to do, there is nobody telling Linux OEMs what to do. Where is the Linux Foundation, offering leadership in this area?


RMS on Free Hardware from LibrePlanet 2015

The Free Software Foundation has released some of the videos from LibrePlanet 2015. The presentation from RMS is described as:

Free software, free hardware, and other things by Richard Stallman, founder of the Free Software Foundation. Richard gives his take on some major issues facing the world of free software and explains how the free software philosophy extends to hardware.

It is a 45-minute video, the first 23 minutes are presentation, the remainder are QA. Video is here:

I have few questions of my own, from watching it:

At the beginning, he mentions that remote attestation of TPM doesn’t work, without any details on why he thinks that. I don’t understand what he’s talking about, there are multiple TNC implemenations, as well as non-TNC equivalent solutions that use TPM for network attestation. Linux-based Chrome OS, StrongSwan for Linux, Linux-IMA or OpenAttestation (OAT) for example.
If someone has more background on his perspective on remote attestation of TPM doesn’t work, please speak up. Heck, even the UEFI firmware on most modern systems have TNC support. IMO, it would have been more interesting to hear a discussion about new TPM 2.0 features, as well as TrustZone on ARM, and how that impacts various Free Software/Firmware/Hardware movements.

Later, he talks about “Free Hardware” term, which AFAICT isn’t that well-defined, and recommends using GPLv3 for hardware, and doesn’t mention OSHWA license, except to say that the alternatives offer no value. I am not sure that the existing OSHWA has the same opinion as RMS with his “Free Hardware” perspective, see March-April thread on the OSHWA list. IMO, Free Hardware -vs- Open Hardware needs some clarification. I guess, like with software, we’ll have the Open camps and the Free camp, with FSF as the Free owner and OSHWA instead of OSI for the Open camps, in addition to the Closed camps. However, unlike ISVs, I’ve never met an OEM or IHV that likes the GPL, so any Free Hardware will likely have to be community-funded, like Novena; I hope the FSF plans community-funded Free Hardware in the coming months.