Firmware customization and flexibility are critical in modern systems, especially when working with open-source projects like coreboot. In this blog post, I will explain the recent development of adding options support in coreboot, a powerful enhancement that allows for seamless configuration transfer between coreboot and its payload, with a special focus on the use case of implementing a Setup Menu using EDKII. This addition solves a long-standing challenge and opens the door for better hardware configuration control.

What is coreboot?

coreboot is an open-source firmware platform designed to perform hardware initialization and then pass control to a payload, such as a bootloader or a full-featured firmware environment like EDKII. Unlike traditional firmware implementations, coreboot is minimalistic and focuses solely on hardware initialization, leaving most of the user interaction and advanced features to the payload.

Understanding EDKII

EDKII (EFI Development Kit II) is an open-source firmware framework commonly used to implement UEFI (Unified Extensible Firmware Interface) support. It is often paired with coreboot as a payload to provide a comprehensive boot solution with advanced features, including the ability to offer a Setup Menu for system configuration.

The Role of cbtables in coreboot

cbtables (coreboot tables) are data structures used within coreboot to pass information between coreboot and its payload. These tables can hold various types of data, such as system information, memory configurations, and platform settings. cbtables ensure that payloads can access necessary information initialized by coreboot during the early boot stages.

The Problem: Lack of Options Support

Before the introduction of options support in coreboot, there was no straightforward way to pass configuration options between coreboot and its payload. This limitation posed challenges for scenarios where a Setup Menu was required.

The Setup Menu is a critical feature for user interaction with firmware settings. Since coreboot's primary role is hardware initialization, a Setup Menu would logically reside in the payload, such as EDKII. However, the inability to exchange configuration options between coreboot and the payload restricted the ability to:

  • Apply user-defined settings at boot time,
  • Change device-specific or coreboot-specific configuration options,
  • Enable/Disable security-related options rooted in coreboot like Intel SGX,
  • Save and persist configuration changes across reboots.

This gap called for a solution where the payload could modify settings and have those settings reflected by coreboot during subsequent reboots.

The Solution: Adding Options Support Using UEFI Variable Store

To address this limitation, we implemented a robust options support system using the UEFI variable store, a non-volatile storage area within flash memory typically used by UEFI firmware for storing configuration data.

How It Works:

Defining Options in coreboot:

  • When building coreboot, the developer can define a set of options that should be supported. These options can include configurations such as boot order, fan control, and security settings.
    For example:
const struct sm_obj_varchar serial_number = {
    .object_id	= atlas_get_object_id(),
    .flags		= CFR_OPTFLAG_READONLY | CFR_OPTFLAG_VOLATILE,
    .opt_name	= "serial_number",
    .ui_name	= "Serial Number",
    .default_value	= "serialnumber",
};

UEFI Variable Store Integration:

  • The payload (e.g., EDKII) writes configuration changes to the UEFI variable store in the system's flash memory.

Reading and Applying Options:

  • On the next reboot, coreboot reads these UEFI variables from the flash memory and applies them during hardware initialization.

cbtables Integration:

  • The defined options in coreboot are also passed to the payload using cbtables, ensuring the payload can build a Setup Menu reflecting the available settings.

User Interaction via Setup Menu:

  • EDKII provides a Setup Menu that allows the user to modify system settings. When settings are changed, EDKII writes the modified options back into the UEFI variable store for coreboot to read during the next boot cycle. These patches are currently not merged upstream.

This approach provides a bidirectional flow of configuration data, ensuring that both coreboot and the payload can stay synchronized regarding system settings.

Why This Matters: Benefits of Options Support in coreboot

The implementation of options support brings several key benefits to coreboot users:

  • Enhanced Flexibility: Users can modify firmware settings dynamically without recompiling coreboot.
  • Improved User Experience: With a Setup Menu in EDKII, users can easily adjust settings through a graphical interface.
  • Persistent Configurations: Changes made in the Setup Menu persist across reboots.
  • Better Payload Integration: Seamless configuration exchange between coreboot and EDKII improves firmware cohesion.

Use Cases: Where Options Support Shines

  1. Secure Boot Configurations: Users can toggle secure boot options directly from the Setup Menu.
  2. Overclocking Controls: Enthusiasts can modify CPU and memory settings without rebuilding coreboot.
  3. Device Management: Adjust boot order and enable/disable devices from the Setup Menu.

Future Improvements and Next Steps

While this feature is a significant advancement, there are still areas for potential improvement:

  • Expanded Payload Support: Extending this options system to other payloads beyond EDKII.
  • Enhanced Security: Implementing additional protections for the UEFI variable store.
  • Automated Testing: Developing automated tests to validate the options transfer mechanism.

Conclusion

The addition of options support in coreboot, specifically for the Setup Menu use case, represents a major step forward for open-source firmware flexibility and usability. By enabling bidirectional configuration exchange between coreboot and its payload, particularly with EDKII's Setup Menu, we have addressed a critical gap in firmware customization.

This enhancement empowers developers and end-users alike, making it easier than ever to configure hardware settings without needing to recompile firmware. Stay tuned for further developments as we continue to innovate in the open-source firmware space.