[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libreboot-dev] C201 Chromebook (veyron_speedy) port and Chromium OS
Re: [Libreboot-dev] C201 Chromebook (veyron_speedy) port and Chromium OS security model
Tue, 11 Aug 2015 11:57:27 +0200
I have just pushed the latest bits of my work on this. Currently, nearly
everything that was supported by the original firmware works just as
well. However, this only implements a RO Coreboot boot path.
In a regular verified boot situation (what Chromium OS implements in
Coreboot), only bootblock and verstage are supposed to be executed from
the Coreboot version stored in the RO part of the flash and the rest is
taken from one of the two half-Coreboot images stored in the RW part of
the flash (half images because they only contain romstage, ramstage and
payload). Those are signed with the firmware key, which is stored in the
Google Binary Block (GBB).
However, in case of recovery booting (when something went wrong), it'll
boot only from the RO Coreboot. I have extended the code to allow
regular booting from the RO Coreboot. This is easier at first because it
doesn't involve generating keys, installing them in GBB, bundling the
"half Coreboot image" and signing it.
The next step will be for me to understand and make it easy to do those
steps, in order to allow a RW Coreboot boot path (verified with those
keys). Making it easy for users to generate and install their own keys
is also mandatory to allow users to sign their kernels with private
keys. Kernels can be signed either with the firmware or the kernel key.
As far as I understood, the firmware and kernel keys are sub-keys of the
root key, that is also stored in the GBB. Those keys are numbered and
the device's TPM is used to safely (it is locked after Coreboot) keep
the key index. Verified boot will refuse to use the key if the key
number is lower than the current count (rollback attack).
I believe there should be two releases in Libreboot: one that is
unsigned and implements the RO boot path and one that follows the
Chromium OS scheme: RO boot path for recovery only and signed RW boot
path for normal or developer boot.
Regarding the payload (depthcharge), I have replaced all the bitmaps by
a text-based interface. There are basically three booting situations:
* Normal mode: nothing is shown on screen, only verified kernels from
internal memory are allowed, there is no menu to change that
* Recovery mode: Users can boot an external recovery media, which is a
kernel signed with the recovery key (independent from the root key). The
Ctrl + D key combination allows entering developer mode, as instructed
* Developer mode: Allows booting from external media (if enabled via the
crossystem utility on the running system) and allows booting unsigned
kernels (if enabled via crossystem too). Developer mode shows a screen
with the useful key combinations for 3 seconds before booting from
internal memory, if not held using the Ctrl + H key combination. It also
shows the active firmware ID, whether it's RO or RW and prints warnings
when unsigned kernels or external media booting is enabled.
The idea is that developer mode should remind users that the system is
somewhat insecure (warning messages) and show what firmware it's running
currently. On the other hand, normal mode should only allow a secure
boot path (trusted kernel from internal memory) since it doesn't show
anything on screen.
The crossystem utility relies on a tool called mosys to access the
non-volatile storage memory used for enabling USB booting and non-signed
kernels. Those can be built on the device (e.g. in Debian) and they are
shipped with ChromeOS (which gives root access when developer mode is
I do not wish to make it possible to enable USB booting or unsigned
kernel from the developer mode menu itself, because it would compromise
the device's security too easily (an attacker would first jump to
recovery move, enable developer mode and then turn off kernel
verification and turn on external media booting to gain root access to
the device via a preloaded USB flash driver). Instead, it should be done
with crossystem on the running system (it is up to the user to secure
All my work is pushed at:
The branches to use are "next". Patches for Coreboot are currently
undergoing review. Perhaps some could be integrated in depthcharge as
well, but most of it won't be (same goes for vboot).
My build scripts to set it all up are at:
I'm off to CCCamp in a few days, hopefully I'll have a somewhat secure
setup to show based on all that in there. Anyone wishing to see a demo
of it running can just come up to me and ask. I'll be at the Neo
Stay tuned for more news after I come back!
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.
Description: This is a digitally signed message part