[Libreboot-dev] C201 Chromebook (veyron_speedy) port and Chromium OS security model

[Paul Kocialkowski]

Now that the patches for adapting the Coreboot build system to the
veyron_speedy and depthcharge builds are undergoing review, it's time to
decide exactly what we want to see in Libreboot for this device.

Chromium OS has a very developed security model, most of which is
implemented in Coreboot. Extensive details about it can be found at:
http://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview

Presentations from the 2014 ChromeOS Firmware summit also explain how
things work in depth:
http://www.chromium.org/chromium-os/2014-firmware-summit

The root of trust is established with the first stages of coreboot
(bootblock and verstage), that are stored in the write-protected part of
the SPI flash (the first 2 MiB). Coreboot itself only takes the first
MiB and other important information is held in the second half:
* fmap: the SPI flash map descriptor, that can be found in depthcharge's
source at: board/veyron_speedy/fmap.dts
* gbb: google binary block, that holds some bitmaps displayed in
depthcharge and most importantly, the public keys used later in the
process
* firmware id: a string describing the firmware ID
* vpd: vital product data, holds some board-specific things, probably
serial number and such

Then, the other half of the SPI flash chip is filled with two RW slots
(A and B), that each contain:
* rw-*-vblock: containing the signature of the boot firmware for the
slot
* rw-*-boot: containing romstage, ramstage, payload and the EC firmware
hash
* rw-*-ec-boot: RW version of the embedded controller firmware
* rw-*-firmware-id: firmware id for the current slot

In addition to that, non-volatile storage is used to store some
configuration options (shown in crossystem), such as whether to allow
booting from an external media, whether to verify the kernel signature
and whether to enable developer mode. This is sometimes saved in the SPI
flash, but in our case, it's stored on the EC's memory
(CONFIG_CHROMEOS_VBNV_EC).

With all that in mind, here is an overview of how things boot according
to the ChromiumOS security model:

1. The RK3288 SoC loads bootblock from the RO coreboot
2. bootblock loads verstage from RO cbfs
3. verstage finds out which RW firmware it should use (A or B) or go to
recovery if there's a problem
4. verstage will check the rw-*-boot signature against rw-*-vblock using
the firmware public key stored in gbb and go to recovery if there's a
problem
5 (recovery). verstage loads romstage from the RO cbfs, boots up to
depthcharge and shows recovery screen
5 (normal). verstage loads romstage from the RW image, which loads
ramstrage and then depthcharge from the RW image
6. depthcharge performs EC software sync, where it asks the EC its RW
firmware hash, compares it with the one in rw-*-boot and uploads
rw-*-ec-boot from the select RW slot if the hash doesn't match
7. depthcharge will, depending on non-volatile storage, shows a
developer mode screen when enabled, allow booting from external medias
and check its signature or not.

We could decide to keep all those features and take profit of them in
Libreboot. However, some are a bit unusual and not critical for ensuring
security. Since the root of trust is the RO firmware, I think it's
enough to keep Lireboot on the RO part of the chip and not care about
the RW firmwares. However, we cannot simply disable all Chrome OS
bindings, because depthcharge relies on it, and there are some other
parts that we might want to keep.

I think it just adds some more work for us and requires changing the
keys preinstalled to verify the firmware, etc. I think we're better off
not tampering with those keys and keep the ability to boot a verified
Chrome OS with those keys (if I got it right, the kernel key is a subkey
of the root firmware key).

Then, there is recovery mode. Recovery mode has its own set of keys
(root recovery key and kernel subkey) and the ones preinstalled are of
course from Google. Recovery mode will be triggered when there is a
problem and provide instructions to reflash ChromeOS, which we don't
want. I think we could keep the recovery mechanism to detect failures
and just print the problem on screen. Sometimes, it might not prevent
booting a kernel, that would provide an environment to fix the problem.
This way, we don't display instructions for ChromeOS and we don't have
to restrict boot to kernels signed using Google's recovery key.

EC software sync should in my opinion be kept, because it is unrelated
to Libreboot (we don't distribute EC firmwares), doesn't hurt, and it
generally speaking a good idea.

Of course, we should modify depthcharge so that it doesn't display the
images encouraging the use of Chrome OS, but instead use text-based
displays that show relevant information (whether we're in developer
mode, whether external media boot is enabled, etc) and when relevant,
provide a key combination (shown on screen) to boot from external media.

What do you think about all this?

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/

signature.asc
Description: This is a digitally signed message part