Chromium: Post-Spectre Threat Model Re-Think

https://twitter.com/fugueish/status/1001605230583136256

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.[…]

https://chromium.googlesource.com/chromium/src/+/master/docs/security/side-channel-threat-model.md

 

AMD AGESA

I’m learning about AMD firmware solutions, and AGESA is first acronym on the list. According to Wikipedia:

“AMD Generic Encapsulated Software Architecture (AGESA), is a bootstrap protocol by which system devices on AMD64-architecture mainboards are initialized. The AGESA software in the BIOS of such mainboards is responsible for the initialization of the processor cores, memory, and the HyperTransport controller. AGESA documentation was previously available only to AMD partners that had signed an NDA. AGESA source code was open sourced in early 2011 to gain track in coreboot.”

There are two firmware ecosystems, coreboot and UEFI, where the former has a lot of Chrome OEMs, and the latter has a lot of Windows OEMs. UEFI and coreboot work on Intel and AMD (and ARM) systems. AMD makes both x86 and ARM systems, but I’m focusing on their x86 systems here.

For coreboot, Sage Engineering is main coreboot IBVs (Independent BIOS Vendors), AFAICT. Sage currently supports AMD systems, offering coreboot with AGESA.

https://www.se-eng.com/products/sagebios-bsp-for-amd-processors/

Sage supports many modern x86 platforms from AMD. In early BSP releases,our source code license allowed us to directly modify and include AGESA source code. Later versions include the AGESA binary PI from AMD to initialize the CPU. SageBIOS(TM) Custom BSPs deliver full-featured firmware designed for AMD platforms.

https://www.se-eng.com/firmware-solutions-for-intel-and-amd-x86-processor-systems/

AMD was the first […] to support an open source boot solution with its support of the One Laptop Per Child program, which was immersed in the Linux open source community, and the Linux firmware boot solutions that would ultimately become coreboot. Sage Electronic Engineering founder Scott Hoot was heavily involved in that the children’s laptop project, as a firmware designer for AMD, and would soon embrace open source firmware solution as a foundation for his startup company. Sage would have distinct advantages over other open source firmware development companies in that Hoot already had a insight into AMD’s proprietary architecture, which he would cement with a agreements with AMD to help forge the way into expanded open source BIOS and firmware coding. Sage would continue to forge a trail in the community with its support of the coreboot(R) solution and the proprietary hybrid that Sage developed for more rapid deployment, SageBIOS. Open source development as a whole continue to progress with AMD’s AGESA  and Intel’s Firmware Support Package, essentially giving open source firmware designers a better look at the architecture than was previously allowed.

Over in the UEFI Forum ecosystem, it appears that most of the ‘mainstream’ IBVs also support ARM via AGESA in their products as well. I see support from Insyde Software and AMI, at least.

http://www.insyde.com/press_news/press-releases/insyde-software-provides-framework-support-amd-processors

http://www.ami.com/news/press-releases/?PressReleaseID=135&/American%20Megatrends%20Extends%20Aptio%C2%AE%20Firmware%20Support%20for%20AMD%20AGESA%E2%84%A2/

I’m still not clear if TianoCore can use AGESA directly, or if an IBV is still needed to integrate the two.

More Information:

http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=src/vendorcode/amd
https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/a46a712610c130cdadfe1ebf6bec9ad22e474dac/src/cpu/amd/agesa
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/AGESA_Interface_specification_for_Arch2008.pdf

[I just realized that I’ve not written a blog on Intel Firmware Support Package (FSP) yet…. I’ll do one in a few days.]