Chrome book Firmware Internals

When the first version of Chrome OS became available, many people were asking the same questions:Why?What can it be used for? How is it different from Android? Out of curiosity, many people downloaded it and played with an earlier version. People quickly discovered that it is a neat idea to build an application environment for connected devices that is bounded by a browser-like framework.

As you read this chapter, you will also learn that Chrome devices are designed to be experimented with. Google has held classes to do just that-showing people how to change the internal firmware and software of a Chrome book. After reading this chapter (and the previous chapter about coreboot), as long as you always preserve a way to restore the original firmware and OS image, you should feel free to experiment with the firmware and OS stack.

Chrome OS Firmware Overview
Chrome OS uses coreboot for all its supported CPU architectures (currently, several different flavors of x86 and ARM devices). This allows for a consistent codebase and designed behaviors across all architectures. Google is committed to open source solutions, and coreboot contains the requisite features and capabilities for booting Chrome OS. coreboot, the firmware layer, provides maximum customization for the optimization of power, performance, and security, with a flexible and consistent firmware OS interface, via ACPI.
The internal operations of coreboot was discussed in the previous chapter, so in this chapter, we will highlight any differences and extensions that have been made to coreboot for Chrome OS devices. You should revisit the previous chapter for specific information about the internals of coreboot.
The Chrome OS firmware image is made up of several pieces: the coreboot hardware initialization code, the Google Depth charge payload, and support binaries and libraries required to boot Chrome OS. The image as a whole is called Chrome OS firmware and it should not to be confused with the embedded controller (EC) firmware or other firmware images within the flash device.

Chrome OS Security Philosophy
Google has designed Chrome OS from the ground up with users' data security in mind. Chrome OS devices use the Google verified boot security library for the chain of trust, which starts in write-protected coreboot romstage.

Chrome OS Security Guiding Principles
The following are Chrome OS security guiding principles:

•
The perfect is the enemy of the good. By realizing that there will never be a perfect solution, the developers of Chrome systems can always ship something good enough to protect the users.
• Deploy defenses in depth. There are a variety of defenses to prevent attacks at different levels, so that even if the attacker can penetrate one level, he can be stopped at other levels, making it difficult for the attacker to persist.
• Make devices secure by default. Security should not be optional, and it should not be a trade-off item competing with performance and ease-of-use. Since firmware, Chrome OS, and software are well-integrated by the developers, there can be a seamless security implementation from top to bottom by default, not as an afterthought.
• Don't scapegoat the user. The design helps the user make decisions only about things they can comprehend, and ensures a fail-safe to make the choice go away when the user does not understand.

Power wash
To further protect user data, a system may be power washed, which securely wipes the user's data on the device and returns the system to the default state. This may be performed at any time via the settings screen.

Chrome OS Boot Modes
Chrome OS supports three separate boot modes. The normal Verified Mode boots a Google-signed Chrome OS image. In case of image corruption or other device failure, Chrome OS has Recovery Mode to reinstall the signed image. The third boot mode is Developer Mode, which allows for advanced features and user-customized sources to be loaded.

Verified (Normal) Mode
Verified boot is the cornerstone for the Chrome OS security, which is implemented in concert with coreboot and the Depth charge payload. Google signs all the binary images that make up a Chrome OS device. This includes the coreboot firmware stages, the embedded controller firmware, and the kernel image. As the system boots, each binary image is cryptographically verified prior to running the image. To protect users, the firmware image enters Recovery Mode if any binary verification fails.

Recovery Mode
If something goes wrong in Chrome OS, the system will boot into Recovery Mode. Recovery Mode runs a protected version of coreboot and gives the user an opportunity to recover the system and return to Normal boot mode. Recovery Mode will only boot a Google-signed USB recovery image. Recovery Mode may be automatically initiated when a software or hardware issue occurs. It may also be initiated directly by the user, typically by pressing the Esc+Refresh+Power buttons. To protect the system during Recovery Mode, the firmware runs the read-only protected version to defend against a problem with a system firmware update or in cases where the system may have been subject to some sort of attack. The read-only version of the firmware can't be overwritten without physical access to the machine, and then only by removing the write-protect screw (which voids the device warranty).

Developer Mode
Developer Mode allows the user to run the Chrome OS system in an unverified mode. This allows more significant software modifications and system controls at the expense of some security. The user may use the root shell, install unsigned and unverified software, run customized images, or even boot a different operating system.
Developer Mode is, essentially, a built-in jailbreak mode that keeps Chrome OS hardware open and enables fair use for all who want to get a Chrome OS device, but are not quite sure whether they want to commit to Chrome OS over the lifetime of the device.

■
entering Developer modeclears the private user data saved while the system is in normal mode. a warning screen is shown to the user on each boot, so they know that the device is not secure. Developer mode may be entered by first entering recovery mode and then pressing Ctrl+D.
Once in Developer Mode, the user may wish to boot something other than Chrome OS. This may be done by enabling the Legacy Mode flags. This loads the SeaBIOS payload instead of the Depth charge payload. SeaBIOS supports USB and normal hard drive INT19 (legacy) -style booting.
To enable legacy boot, the following flag must be set via the root shell.

Chrome OS Coreboot
Chrome OS is developed on several CPU architectures. Currently, x86, ARM (including ARM64), and MIPS are supported; each architecture requires custom firmware.

x86
For the x86 architecture, the Chrome OS coreboot does not use the Intel FSP as described in the coreboot chapter. It has a smaller Intel firmware binary image, similar to the FSP, and the firmware binary image is specifically tailored to meet the performance and boot time requirements for Chrome OS. The Intel firmware binary image contains subsections of the Memory Reference Code (MRC) and System Agent code.

Note ■
as this book is written, Google has come down the path of using mrC binary in the firmware stack, and intel Fsp was made available later. there is an ongoing evaluation effort between intel and Google to decide on the best solution for future projects. in other words, mrC and intel Fsp may converge in the near future. ARM x86 is well represented in the coreboot codebase. coreboot was originally designed around PCI standards first introduced in x86. Google has combined x86 and ARM support into a common codebase. ARM wasn't discussed in the previous coreboot chapter, so we will give a brief overview here.
The number of ARM SOCs supported in coreboot at this time is still significantly behind the number of x86 processors and chipsets, but the number is steadily increasing. The first ARM SOC that started off ARM architecture support in coreboot was the Samsung Exynos 5250, which was added as an experimental proof of concept. Since then, several SOCs have been supported, including newer Exynos, Nvidia Tegra, and Qualcomm devices. Similar to x86, some of the systems require certain binary-only components-like a signed first-stage bootloader or a microcode-to fully function.

Depth charge Payload
The Google Depth charge payload has a single, focused goal: to securely boot Chrome OS. It is designed to be simple, small, and easy to learn. Being simple and small, it has a quick load time, fast execution, a small attack surface, and is generally very efficient. Depth charge uses two libraries: vboot and libpayload. Depth charge is loaded by coreboot just as any other coreboot payload. It resides in CBFS and is loaded immediately after coreboot has initialized the hardware. The code flow is fairly simple, as shown in Figure 5-1.

Figure 5-1. Verified boot flow with Depthcharge payload
Depth charge will only load Chrome OS and can't boot any other operating system. Depth charge can chain load other payloads in Developer Mode, which may be used to load an additional payload, like SeaBIOS, which may load other operating systems. libpayload Depth charge is built upon lib payload. As mentioned in the "Payloads" section of Chapter 4, lib payload is a library of common payload functions and hardware drivers provided by coreboot. It is used by Depth charge and has the following lib payload features: A subset of libc and other utility functions • malloc/free, printf, "string" functions, rand, *delay, etc. Verified boot is used within coreboot and Depth charge to ensure that only signed code is executed. It is based on security standards starting with a Root of Trust. The Root of Trust on Chrome OS devices is in read-only (RO) firmware protected by physical hardware write protection. The device reset vector (the first instructions executed) is in the RO area of flash (see Figure 5-2). Then, the RO firmware verifies a signed read-write (RW) firmware (VB_Firmware). (The RW firmware may be updated to fix issues in the field). The RW firmware verifies the Chrome OS kernel signature (VB_Kernel) prior to loading it.

Verified Boot and Kernel Security
After the firmware has verified and loaded the kernel, the Root hash is passed to the kernel-on-kernel command line by Depthcharge. The kernel continues the Root of Trust-based security model and mounts the root filesystem as read-only (see Figure 5-3). The kernel security hashes each block in the image. The block hashes are bundled and structured in a tree, and subsequent read blocks are hashed and checked against the tree. The hash tree is stored in the page cache.

Chrome OS Firmware Boot Log
Traditionally, coreboot sends its boot console log messages to a serial port. The coreboot and Depth charge firmware boot log is saved to CBMEM on Chrome OS systems. This log is extremely helpful in debug and it contains useful information to the curious user. In Chrome OS, the boot log is available in the system information at chrome://system and by then clicking on the Expand button under bios_log.
In Developer Mode, the boot log is easy to access in /sys/firmware/log:

Chrome OS Firmware Event Log
The coreboot boot log in CBMEM contains a lot of detailed information about the current boot, but it is lost when the system reboots and cannot be accessed when the system is in a nonbootable state. In order to debug issues across several reboots, all coreboot-based Chrome OS systems have a persistent log of system events. The event log is based on SMBIOS Type 15 Event Log format, but uses a number of OEM events to provide additional information. The mosys application that is part of Chrome OS can be used to read and decode the log by running the mosys event log list as the root user in Chrome OS if the device is in Developer Mode, or by opening chrome://system and looking for the event log entry in Normal/Verified mode.

Google SMI Linux Kernel Driver
The Google SMI kernel driver implements a kernel interface to talk to the firmware's System Management Interrupt (SMI) handler. It allows kernel events to be stored in the firmware event log. The driver hooks into kernel notifier chains and records the following conditions to the log:

Chrome OS Extensions to the Firmware Image
As discussed in previous sections, Google has added a number of features and capabilities that are beyond a standard coreboot firmware image. These extensions cohabitate within the firmware image along with coreboot, payloads, and vendor binaries. The extensions in the following subsections were added to help facilitate the many features in the flash image. FMAP FMAP is a simple specification for the layout of flash devices. It doesn't make assumptions about the underlying technology. For example, it may be used by coreboot, Legacy BIOS, UEFI, and EC images. FMAP only defines regions in flash. Unlike the coreboot file system CBFS, FMAP defines fixed-size regions.

BOOT_STUB FMAP Section
The BOOT_STUB section contains the reset vector location at the end of the rom (for x86), as well as all the read-only firmware. This includes the coreboot rom stage and verified boot image used by the normal verified boot path. It also contains the complete RO firmware for Recovery Mode, which includes read-only versions of coreboot ram stage and Depth charge.

Chrome OS Firmware RW FMAP Sections
Chrome OS firmware contains two read-write sections. These are updated separately in case there is a problem with the update process. When a firmware update happens, only one of the sections is updated with a new image. Once the system has booted successfully with the new firmware, the old firmware in the other section is overwritten with the new firmware. If the firmware update fails, the system will automatically fall back to the old, known good firmware. A Chrome OS firmware FMAP RW Section example is shown in Table 5-2.

Google Binary Block (GBB)
The Google Binary Block (GBB) is a simple binary storage interface for Chrome OS devices. It is stored in a region in read-only firmware and located via the FMAP. It contains the following information:

GBB: HWID v3
The Hardware identifier is unique for each Chrome OS device model. It is generated by an algorithm that catalogs all HW and FW components, as well as the platform name, build phase, and the RO firmware version. It is generated for each board during the factory process. HWID is used to uniquely identify each platform hardware variant to ensure compatibility during recovery and updates.

GBB: Firmware Bitmaps
The firmware image screens for Recovery Mode help and Developer Mode warnings are included in the GBB area. These images have localized text overlays for the transition to and from Recovery and Developer modes. The user can switch between locales with arrow keys. The images are LZMA-compressed bitmaps to minimize space and they must be available for the RO firmware.

GBB: Firmware Keys
Public keys in GBB are used for verification of the binaries, which are signed by the Google private keys during the build process. The binary data is not encrypted; it is only hashed. The GBB contains the Root and Recovery Public Keys, which are RSA-8192 + SHA-512. Subsequent keys are smaller. Each signing key is versioned and the Verified boot will reject lower versions.

GBB: Boot Flags
The boot flags are flags that alter the Chrome OS boot path. They override the nonvolatile flags set with the crossystem tool. The flags are used to enable alternate booting for the factory process, but they can also be used by the end user to customize a boot after entering Developer Mode and disabling write protect. A list of the boot flags is located in Table 5-3. Firmware TPM Usage TPM stands for Trusted Platform Module. It is a specialized chip on an endpoint device that stores RSA encryption keys specific to the host system for hardware authentication.
Chrome OS's verified boot library uses the TPM for the following tasks: Preventing software and firmware version rollback •

Maintaining information to detect transitions between Normal • and Developer Modes
Protecting user data encryption keys • Protecting certain user RSA keys ("hardware-backed" certificates) •

Protecting state ful partition encryption keys •
Attesting TPM-protected keys •

Attesting device mode •
The TPM is not directly available outside of Chrome OS for any purpose; that is, no remote software or system may have access to the TPM.
Chrome OS does not use the TPM for the following: • Trusted boot: The TPM is not used as part of the Chrome OS verified boot solution.
• Hardware: Strength platform configuration reporting.
• Whole-disk encryption or similar: In particular, the TPM is not used to unwrap an encryption key during the boot process.

Chrome OS Firmware Update
The Chrome OS read-write area of the flash may be updated by the auto-update process. When required, Chrome OS downloads the firmware update as a self-contained firmware update package. All the binaries and scripts embedded into the shell archive, as well as the firmware images for the system flash and the EC flash. The flashrom utility is part of the package and is used to flash both the Chrome OS firmware image and the EC image. As shown in the "FMAP" section of this chapter, the Chrome OS firmware has two read-write images. The update process begins with flashing one region, rebooting, verifying that the new image works, and then flashing the second region. This process should prevent the system from becoming unusable if there is an update issue. Figure 5-4 shows the process of the RW image update process.

Note
■ the internal write protect screw on the mainboard must be removed to write the Gbb region.

Usage: set_gbb_flags.sh [option_flags] GBB_FLAGS_VALUE
crossystem The crossystem tool is used to gather information about the Chrome OS device's system flags, boot modes, VPD, GBB, NVRAM information, and binary versions.
Get vital system data: Like other areas of Chrome OS, the Chrome EC is designed for security. It has readonly and read-write regions. The read-write binary update is called Software Sync. The sync is handled by Depth charge and verified boot. The Chrome EC firmware has support for several different ARM SOCs, including Texas Instruments Stellar is Cortex-M4 and the ST Micro STM32 Cortex-M3.

Power Sequencing
Each application processor family has its own power sequencing requirements. The EC must manage and respond to all those requirements across the different system states, like boot, sleep, and idle. It also ensures that some peripherals are brought up and down as directed by system drivers; for example, USB and Wi-Fi devices.

Battery Charging
Most Chrome books use Smart Battery technology. This is a fairly simple system, where the battery asks for specific voltage and current, and the charger circuitry responds accordingly. The EC handles a few special cases: Trickle charge a fully discharged battery • Custom charge requirements for high-or low-power conditions • Keeping temperatures within safe operating ranges • Note ■ reference materials are located at http://sbs-forum.org/specs/sbdat110.pdf.

Thermal Management
The Chrome EC firmware supports several different thermal modes. It can act on independent thresholds and deliver host events via ACPI and the system PROCHOT signal. It also has configuration for fan speeds and can force the system power off, based on any sensor readings.

Keyboard Controller
For x86-based systems, the EC provides a "standard" 8042 AT-style interface. ARM-based systems use a binary format that merely sends the scan matrix up to the kernel. In either case, the keyboard scan matrix is defined in the board-specific firmware configuration.

Other Peripheral Controls
The Chrome EC also controls the following devices: LED behavior (battery charging, full, power on, etc.)

Chrome EC Software Sync
It is important that the AP firmware (coreboot) and the EC firmware remain compatible through upgrades. During every Normal Mode boot, the EC firmware is verified by the AP firmware and updated, if required. In Recovery Mode, the EC and AP firmware stay in read-only mode.