Chromium: Post-Spectre Threat Model Re-Think

In light of Spectre/Meltdown, we needed to re-think our threat model and defenses for Chrome renderer processes. Spectre is a new class of hardware side-channel attack that affects (among many other targets) web browsers. This document describes the impact of these side-channel attacks and our approach to mitigating them. The upshot of the latest developments is that the folks working on this from the V8 side are increasingly convinced that there is no viable alternative to Site Isolation as a systematic mitigation to SSCAs [speculative side-channel attacks]. In this new mental model, we have to assume that user code can reliably gain access to all data within a renderer process through speculation. This means that we definitely need some sort of ‘privileged/PII data isolation’ guarantees as well, for example ensuring that password and credit card info are not speculatively loaded into a renderer process without user consent. […] In fact, any software that both (a) runs (native or interpreted) code from more than one source; and (b) attempts to create a security boundary inside a single address space, is potentially affected. For example, software that processes document formats with scripting capabilities, and which loads multiple documents from different sources into the same process, may need to take defense measures similar to those described here.[…]


proposed driver model for U-Boot init

Simon Glass of Chromium posted an 16-part patch to the U-Boot list, adding a driver model to the U-Boot init sequence.

[PATCH 00/16] RFC: Board init using driver model

At present we have a lot of ad-hoc init functions related to boards, for example board_early_init_f(), board_misc_init_f() and dram_init(). There are used in different ways by different boards as useful hooks to do the required init and sequence it correctly. Some functions are always enabled but have a __weak default. Some are controlled by the existence of a CONFIG. There are two main init sequences: board_init_f() (f for running from read-only flash) which runs before relocation and board_init_r() (r for relocated) which runs afterwards. One problem with the current sequence is that it has a lot of arch-specific #ifdefs around various functions. There are also #ifdefs for various features. There has been quite a bit of discussion about how to tidy this up and at least one RFC series[1].

Now that we have driver model we can use this to deal with the init sequences. This approach has several advantages:
– We have a path to remove the #ifdefs
– It is easy for multiple parts of the code to implement the same hook
– We can track what is called and what is not
– We don’t need weak functions
– We can eventually adjust the sequence to improve naming or to add new init phases
– It provides a model for how we might deal with ft_board_setup() and friends

This series starts the process of replacing the pre-relocation init sequence with a driver-model solution. It defines a uclass, adds tests and converts sandbox and a few x86 boards over to use this new setup. This series is not ready for use yet as the rest of the init sequence hooks need to be converted. But there is enough here to show the idea.

Comments welcome.


37 files changed, 980 insertions(+), 45 deletions(-)
create mode 100644 doc/driver-model/board-info.txt

More information:

U-Boot ported to Intel64

Simon Glass of Chromium posted a *82-part* patch to the U-Boot list, with a port of U-Boot from 32-bit x86 to 64-bit x64 support. Quoting Simon’s initial message:

[PATCH 00/82] x86: Add initial support for 64-bit U-Boot

At present U-Boot runs entirely in 32-bit mode on x86, except for the initial switch from 16-bit mode. On 64-bit machines it is possible to run in 64-bit mode. This series starts the process of adding this support. The main benefit of 64-bit mode for a boot loader is direct access to all available memory. There are also more registers, but this makes very little difference. This feature is implemented by putting all of the 32-bit code in an SPL build. SPL then runs through all the init that has to be done in 32-bit mode, changes to 64-bit mode and then jumps to U-Boot proper. Typically the total code size increases slightly. For example, on link in 32-bit mode, U-Boot has around 480KB of code (admittedly with a large number of features enabled). In 64-bit mode, U-Boot falls to around 460KB, but SPL adds another 60KB, for a net increase of 40KB. Partly this is due to code duplication and partly it is due to the worse code density of 64-bit code on x86. Many major features are not implemented yet, for example:
  – SDRAM sizing
  – Booting linux
  – FSP support
  – EFI support
  – SCSI device init
  – Running video ROMs
Still, this is a big step forward towards full 64-bit support. To enable it, select CONFIG_X86_RUN_64BIT. This series is available at u-boot-x86/64-working.

91 files changed, 1796 insertions(+), 705 deletions(-)
See full description in the post:

binman: new U-Boot firmware image creation tool

Simon Glass of Chromium submitted “binman”, a new firmware image creation tool, to the U-Boot project. Below is the intro from Simon’s patch 0/30:

binman: A tool for creating firmware images

This series introduces binman, a tool designed to create firmware images. It provides a way to bring together various binaries and place them in an image, at particular positions and with configurable alignment.

Packaging of firmware is quite a different task from building the various parts. In many cases the various binaries which go into the image come from separate build systems. For example, ARM Trusted Firmware is used on ARMv8 devices but is not built in the U-Boot tree. If a Linux kernel is included in the firmware image, it is built elsewhere.

It is of course possible to add more and more build rules to the U-Boot build system to cover these cases. It can shell out to other Makefiles and build scripts. But it seems better to create a clear divide between building software and packaging it.

U-Boot supports a very large number of boards. Many of these have their own specific rules for how an image should be put together so that it boots correctly. At present these rules are described by manual instructions, different for each board. By turning these instructions into a standard format, we can support making valid images for any board without manual effort, lots of READMEs, etc.

Images consist of a number of entries which are combined to make up the final image. The image is described in the device tree for the board, meaning that it can be accessed at run-time if desired.

Binman is an extensible tool. A set of standard entries is provides, but new entries can be created fairly easily. Entries can be as simple as providing the name of a file to include. They can also handle more complex requirements, such as adjusting the input file or reading header information from one entry to control the position of another.

U-Boot’s mkimage builds FIT images and various other binaries. Binman augments this by allowing these binaries to be packed together. While FIT should be used where possible, it cannot be used everywhere. For example, many devices require executable code at a particular offset in the image. X86 machines require lots of binary blobs at particular places, and a microcode collection easily accessible at boot.

So far binman has enough functionality to be useful, but apart from a few RFC patches, no attempt is made to switch boards over to use it. There should be enough material to permit review and comments.

The series is available at u-boot-dm/binman-working

Future work and missing features are documented in the README.

For more info, see the patch on the U-Boot list:

Hyper-V Chromium bug status

Kostya Kortchinsky pointed out some Hyper-V bugs recently fixed in Chromium, all 3 are listed as being fixed 4 days ago.
Hyper-V vmswitch.sys VmsMpCommonPvtHandleMulticastOids Guest to Host Kernel-Pool Overflow
Hyper-V vmswitch.sys VmsVmNicHandleRssParametersChange OOBR Guest to Host BugChecks
Hyper-V vmswitch.sys VmsPtpIpsecTranslateAddv2toAddv2Ex OOBR Guest to Host BugCheck

Microsoft and ARM collaborate on DRM/secure media solutions

ARM and Microsoft have announced support of integration of technologies that enable DERM on ARM systems, using Microsoft PlayReady and W3C Encrypted Media Extensions (EME):

Press release excerpt:

The major development in this solution is the integration of Microsoft’s PlayReady DRM with W3C EME, OpenCDM, Chromium and Linaro’s Open Portable Trusted Execution Environment (OP-TEE) on ARM TrustZone® technology. The secure media solution has been implemented on an STMicroelectronics STiH410 SoC with an ARM Cortex®-A9 processor at its core. The new solution integrates the following key components: W3C EME, Microsoft PlayReady DRM Porting Kit v3.0, OP-TEE, OpenCDM, and Chromium v43.

“The Linaro Digital Home Group is extremely pleased to deliver this open source secure media solution to the embedded developer community” said Mark Gregotski, Director of the Linaro Digital Home Group. “This collaboration demonstrates how a commercial DRM, such as Microsoft’s PlayReady, can be integrated into a security framework comprised of open-source components, including the Linaro Open Portable TEE running on ARM TrustZone. We hope this will be the catalyst to accelerate the deployment of secure DRM solutions employing open source software.”

“This is a key milestone that showcases how Microsoft PlayReady DRM works cross-platform in a standard way. We are excited about the collaboration with Linaro, ARM, OP-TEE and OpenCDM. This reference implementation simplifies and accelerates the ability of partners to build rich experiences to deliver secure media solutions, while providing market leading content protection using Microsoft PlayReady” said Dave Bossio, Group Program Manager, Windows Devices Group, Security at Microsoft Corporation.

“Trust is key to future media business models, as valuable content must be protected from server to screen,” said Shiv Ramamurthi, Director, Home Segment Marketing, ARM. “The pay TV ecosystem will see immediate content security benefits from the integration of ARM TrustZone and Microsoft PlayReady DRM technology. This latest open source initiative led by the Linaro Home Group is a milestone in the enablement of next-generation secure content and media experiences for consumers.”

“ST has been a strong contributor to the Open Portable Trusted Execution Environment (OP-TEE) in open source, a key enabler for this integration. As a natural step forward, ST is pleased its STiH410 platform is being used as a vehicle for this effort and for an exciting demo at IBC 2015,” said Yingchih Yang, Advanced System and Security Officer of the Consumer Product Division in STMicroelectronics. “Such Linaro contributions will facilitate premium content consumption across various devices including smartphones, tablets, and set-top-boxes, meeting strong market expectations.”

U-Boot TPM driver model added

Yesterday Simon Glass of Chromium has submitted a large (28-part) patch to U-Boot, adding a driver model for TPMs.

[PATCH v2 00/28] dm: Convert TPM drivers to driver model

This series adds driver model support for Trusted Platform Modules (TPMs). These have a very simple interface and are configured via the device tree.

Two bus types are supported at present: I2C and LPC (Intel Low-Pin-Count).

Most drivers and users are converted over to driver model. The exception is the Atmel TPM and its users.

The I2C driver has been cleaned up and simplified. It was ported from Linux and was pretty hard to follow. This series includes patches to unify the code, remove duplicated data structures and drop unnecessary indirection.

Also this series enables the TPM on all Chromebooks supported by upstream U-Boot (snow, spring, nyan-big, pit, pi, link, panther) since some did not have it fully enabled.

As before, the ‘tpm’ command can be used to implement TPM functionality. In addition a ‘tpmtest’ command provides some basic TPM tests taken from Chrome OS U-Boot. These are fairly rudimentary but are useful if you know what you are doing.

For more information, see the U-boot mailing list: