OSFC 2018 - coreboot rompayload | Ron Minnich

Summary

In this tech talk, the speaker delves into the concept of RAM payloads in firmware, contrasting them with the traditional ROM stage. They recount the history of Linux BIOS and the evolution of the RAM stage, which was initially designed to overcome limitations in Linux. The speaker argues for the potential redundancy of the RAM stage in modern systems, especially with advancements in Linux's capabilities. They also discuss the move towards eliminating runtime firmware services due to trust issues and advocate for a simplified boot process, demonstrating a live test of a RAM payload in coreboot, highlighting its efficiency and potential for future boot systems.

Takeaways

• 😀 The speaker experimented with a 'random payload' approach, inspired by Trammell's picture of Vincent, which involves loading a payload directly from the ROM stage instead of using a RAM stage.
• 📝 The speaker emphasized the importance of having an outline for a talk, but also the need to go beyond a basic outline for better informativeness.
• 🔍 The RAM stage's function is to discover, allocate, configure, and enable resources before booting, and it has been evolving since 2007 with the introduction of SMM (System Management Mode).
• 🚫 The speaker expressed concerns about the trustworthiness of firmware, advocating for an 'air gap' approach where the firmware runs and then never communicates back, to avoid potential security issues.
• 🛠️ The speaker discussed the history and evolution of the ROM stage and RAM stage, including the initial challenges with Linux and the development of the device model in coreboot.
• 🔧 The speaker shared personal anecdotes about working with Linux BIOS and the evolution of the Linux kernel, including issues with PCI device enabling and the incorporation of PCI enumeration code.
• 🔄 The speaker questioned the necessity of the RAM stage given the growing capabilities of Linux, suggesting that in some cases, the RAM stage might be redundant.
• 💡 The idea of a RAM payload was presented as a potential simplification of the boot process, where the payload is loaded directly from ROM without the need for a RAM stage.
• 🔗 The speaker touched on the complexities and potential security risks of UEFI (Unified Extensible Firmware Interface) and the desire to move towards a more streamlined boot process.
• 🛑 The speaker critiqued the current signing models in firmware, arguing for more user control over their machines and against vendor lock-in.
• 🔄 The speaker concluded with a demo of the RAM payload in action, showing its practical application and performance, and opened the floor for questions and further discussion.

Q & A

What is the main topic of the speaker's presentation?

The speaker is discussing the concept and implications of RAM payloads in the context of firmware and operating systems, particularly focusing on their evolution, necessity, and potential redundancy with advancements in technology.

What does the speaker mean by 'random payload'?

A 'random payload' in this context refers to a payload loaded from the ROM stage instead of loading a RAM stage, which is a departure from the traditional method of loading payloads for booting up systems.

What is the purpose of the RAM stage according to the speaker?

The RAM stage is designed to discover, allocate, configure, and enable resources before booting the system. It also serves as a means of communicating this information to the payload.

Why did the speaker attempt to implement a RAM payload?

The speaker was inspired by Trammell's picture of Vincent and wanted to explore whether the RAM payload method could work effectively, although it didn't work as intended due to banding issues.

What is the speaker's view on the necessity of the RAM stage in modern systems?

The speaker questions the necessity of the RAM stage, suggesting that with the growth in capabilities of operating systems like Linux, the functions traditionally performed by the RAM stage might be redundant.

What is the speaker's stance on the use of SMM (System Management Mode)?

The speaker expresses a negative view of SMM, stating that it was considered a bad idea even in the early 2000s and that they would prefer not to have it running on systems due to security concerns.

What is the speaker's opinion on the current state of firmware in systems?

The speaker criticizes the current state of firmware, describing it as a large, complex operating system that often contains vulnerabilities and is a source of vendor lock-in.

What is the speaker's suggestion for handling firmware updates?

The speaker suggests that instead of relying on firmware updates that require reflashing, systems should allow for the kernel to supply M mode code, which can be updated simply by rebooting.

What is the 'air gap' concept mentioned by the speaker?

The 'air gap' concept refers to a design choice where components are loaded by other components without any communication back, which is intended to prevent trust issues with untrusted firmware.

What is the speaker's view on the future of firmware and operating system interactions?

The speaker advocates for a future where operating systems have more control over their environment, including the ability to supply their own M mode code, rather than relying on potentially untrustworthy firmware.

What is the speaker's final recommendation regarding the RAM stage?

The speaker recommends revisiting the necessity of the RAM stage in light of modern capabilities of operating systems and suggests that direct payload loading from the ROM stage could be a viable alternative.