Coreboot

Last updated

coreboot
Original author(s) Ronald G. Minnich, Eric Biederman, Li-Ta (Ollie) Lo, Stefan Reinauer, and the coreboot community
Initial release1999;25 years ago (1999)
Stable release
24.08 [1]   OOjs UI icon edit-ltr-progressive.svg / 2 September 2024;2 months ago (2 September 2024) [2]
Repository
Written inMostly C, about 1% in assembly and optionally SPARK
Platform IA-32, x86-64, ARMv7, [3] ARMv8, MIPS, RISC-V, POWER8
Type Firmware
License GPLv2-only [4]
Website www.coreboot.org   OOjs UI icon edit-ltr-progressive.svg

coreboot, formerly known as LinuxBIOS, [5] is a software project aimed at replacing proprietary firmware (BIOS or UEFI) found in most computers with a lightweight firmware designed to perform only the minimum number of tasks necessary to load and run a modern 32-bit or 64-bit operating system.

Contents

Since coreboot initializes the bare hardware, it must be ported to every chipset and motherboard that it supports. As a result, coreboot is available only for a limited number of hardware platforms and motherboard models.

One of the coreboot variants is Libreboot, a software distribution partly free of proprietary blobs, aimed at end users.

History

The coreboot project began with the goal of creating a BIOS that would start fast and handle errors intelligently. [6] It is licensed under the terms of the GNU General Public License version 2 (GPLv2). Main contributors include LANL, SiS, AMD, Coresystems and Linux Networx, Inc, as well as motherboard vendors MSI, Gigabyte and Tyan, which offer coreboot alongside their standard BIOS or provide specifications of the hardware interfaces for some of their motherboards. Google partly sponsors the coreboot project. [7] CME Group, a financial public company, began supporting the coreboot project in 2009. [8]

Other than the first three models, all Chromebooks run coreboot. [9] Code from Das U-Boot has been assimilated to enable support for processors based on the ARM instruction set. [10]

In June 2019, coreboot began to use the NSA software Ghidra for its reverse engineering efforts on firmware-specific problems following the release of the suite as free and open source software. [11]

Supported platforms

CPU architectures supported by coreboot include IA-32, x86-64, ARM, ARM64, MIPS and RISC-V. Supported system-on-a-chip (SOC) platforms include AMD Geode, starting with the Geode GX processor developed for the OLPC. Artec Group added Geode LX support for its ThinCan model DBE61; that code was adopted by AMD and further improved for the OLPC after it was upgraded to the Geode LX platform, and is further developed by the coreboot community to support other Geode variants. coreboot can be flashed onto a Geode platform using Flashrom.

From that initial development on AMD Geode based platforms, coreboot support has been extended onto many AMD processors and chipsets. The processor list includes Family 0Fh and 10h (K8 core), and recently Family 14h (Bobcat core, Fusion APU). coreboot support also extends to AMD chipsets: RS690, RS7xx, SB600, and SB8xx.

In AMD Generic Encapsulated Software Architecture (AGESA)a bootstrap protocol by which system devices on AMD64 mainboards are initializedwas open sourced in early 2011, aiming to provide required functionality for coreboot system initialization on AMD64 hardware. [12] However, as of 2014 such releases never became the basis for future development by AMD, and were subsequently halted. [13]

Devices that could be preloaded with coreboot or one of its derivatives include:

Lenovo/IBM
The Libreboot T400 and X200 (rebranded ThinkPad T400 and X200, respectively, available from Minifree, previously known as Gluglug). [14] [15]
Artec Group
ThinCan models DBE61, DBE62 and DBE63, and fanless server/router hardware manufactured by PC Engines. [16]
Purism
Librem laptops come with coreboot. [17] [18]
Others
Some System76 PCs use coreboot TianoCore firmware, including open source Embedded Controller firmware.
Dasharo offers an alternative coreboot-based firmware distribution for computers from MSI, NovaCustom and Nitrokey, among others. [19] [20] [21]
StarLabs Systems use coreboot firmware, as an alternative. [22]

Design

Coreboot typically loads a Linux kernel, but it can load any other stand-alone ELF executable, such as iPXE, gPXE or Etherboot that can boot a Linux kernel over a network, or SeaBIOS [23] that can load a Linux kernel, Windows 2000 and later, and BSDs; Windows 2000/XP and OpenBSD support was previously provided by ADLO. [24] [25] coreboot can also load a kernel from any supported device, such as Myrinet, Quadrics, or SCI cluster interconnects. Booting other kernels directly is also possible, such as a Plan 9 kernel. Instead of loading a kernel directly, coreboot can pass control to a dedicated boot loader, such as a coreboot-capable version of GNU GRUB 2.

Coreboot is written primarily in C, with a small amount of assembly code. Choosing C as the primary programming language enables easier code audits when compared to contemporary PC BIOS that was generally written in assembly, [26] which results in improved security. There is build and runtime support to write parts of coreboot in Ada [27] to further raise the security bar, but it is currently only sporadically used. The source code is released under the GNU GPL version 2 license.

Coreboot performs the absolute minimal amount of hardware initialization and then passes control to the operating system. As a result, there is no coreboot code running once the operating system has taken control. A feature of coreboot is that the x86 version runs in 32-bit mode after executing only ten instructions [28] (almost all other x86 BIOSes run exclusively in 16-bit mode). This is similar to the modern UEFI firmware, which is used on newer PC hardware.

Initializing DRAM

The most difficult hardware that coreboot initializes is the DRAM controllers and DRAM. In some cases, technical documentation on this subject is NDA restricted or unavailable. RAM initialization is particularly difficult because before the RAM is initialized it cannot be used. Therefore, to initialize DRAM controllers and DRAM, the initialization code may have only the CPU's general purpose registers or Cache-as-RAM as temporary storage.

romcc, a C compiler that uses registers instead of RAM, eases the task. Using romcc, it is relatively easy to make SMBus accesses to the SPD ROMs of the DRAM DIMMs, that allows the RAM to be used.

With newer x86 processors, the processor cache can be used as RAM until DRAM is initialized. The processor cache has to be initialized into Cache-as-RAM [29] [30] mode as well, but this needs fewer instructions than initializing DRAM. Also, the Cache-as-RAM mode initialization is specific to CPU architectures, thus more generic than DRAM initialization, which is specific to each chipset and mainboard.

For most modern x86 platforms, closed source binary-only components provided by the vendor are used for DRAM setup. For Intel systems, FSP-M is required, while AMD has no current support. Binary AGESA is currently used for proprietary UEFI firmware on AMD systems, and this model is expected to carry over to any future AMD-related coreboot support. [31]

Developing and debugging coreboot

Hacking coreboot at Denver 2008 summit. Hacking Coreboot.jpg
Hacking coreboot at Denver 2008 summit.

There are also CPU emulators that either replace the CPU or connect via a JTAG port, with the Sage SmartProbe [32] [33] being an example. Code can be built on, or downloaded to, BIOS emulators rather than flashing the BIOS device.

Payloads

SeaBIOS payload running on a Lenovo ThinkPad X60 Coreboot+seaBIOS+on-x60.JPG
SeaBIOS payload running on a Lenovo ThinkPad X60

coreboot can load a payload, which may be written using the libpayload helper library. Existing payloads include the following:

European Coreboot Conference

One physical meeting is the European Coreboot Conference which was organized in October 2017 and lasted for three days.

Conference history

Event and yearDateHost cityVenueResourcesThemes
ECC201726.10. – 29.10 Bochum, Germany RUB Convention Center https://ecc2017.com

Variants

coreboot has a number of variants from its original code base each with slightly different objectives:.

See also

Related Research Articles

<span class="mw-page-title-main">BIOS</span> Firmware for hardware initialization and OS runtime services

In computing, BIOS is firmware used to provide runtime services for operating systems and programs and to perform hardware initialization during the booting process. The firmware comes pre-installed on the computer's motherboard.

<span class="mw-page-title-main">Booting</span> Process of starting a computer

In computing, booting is the process of starting a computer as initiated via hardware such as a button on the computer or by a software command. After it is switched on, a computer's central processing unit (CPU) has no software in its main memory, so some process must load software into memory before it can be executed. This may be done by hardware or firmware in the CPU, or by a separate processor in the computer system.

<span class="mw-page-title-main">MemTest86</span> Computer memory diagnostics software

MemTest86 and Memtest86+ are memory test software programs designed to test and stress test an x86 architecture computer's random-access memory (RAM) for errors, by writing test patterns to most memory addresses, reading back the data, and comparing for errors. Each tries to verify that the RAM will accept and correctly retain arbitrary patterns of data written to it, that there are no errors where different bits of memory interact, and that there are no conflicts between memory addresses.

<span class="mw-page-title-main">UEFI</span> Technical specification for firmware architecture

Unified Extensible Firmware Interface is a specification for the firmware architecture of a computing platform. When a computer is powered on, the UEFI-implementation is typically the first that runs, before starting the operating system. Examples include AMI Aptio, Phoenix SecureCore, TianoCore EDK II, InsydeH2O.

<span class="mw-page-title-main">Power-on self-test</span> Process performed by firmware or software routines

A power-on self-test (POST) is a process performed by firmware or software routines immediately after a computer or other digital electronic device is powered on.

In computer science, execute in place (XIP) is a method of executing programs directly from long-term storage rather than copying it into RAM. It is an extension of using shared memory to reduce the total amount of memory required.

Advanced Configuration and Power Interface (ACPI) is an open standard that operating systems can use to discover and configure computer hardware components, to perform power management, auto configuration, and status monitoring. It was first released in December 1996. ACPI aims to replace Advanced Power Management (APM), the MultiProcessor Specification, and the Plug and Play BIOS (PnP) Specification. ACPI brings power management under the control of the operating system, as opposed to the previous BIOS-centric system that relied on platform-specific firmware to determine power management and configuration policies. The specification is central to the Operating System-directed configuration and Power Management (OSPM) system. ACPI defines hardware abstraction interfaces between the device's firmware, the computer hardware components, and the operating systems.

<span class="mw-page-title-main">Hackintosh</span> Non-Apple computer running macOS

A Hackintosh is a computer that runs Apple's operating system macOS on computer hardware that is not authorized for the purpose by Apple. This can also include running Mac software on hardware it is not originally authorized for. This is due to the software license for macOS only permitting its use on in-house hardware built by Apple itself, in this case the Mac line.

In the x86-64 computer architecture, long mode is the mode where a 64-bit operating system can access 64-bit instructions and registers. 64-bit programs are run in a sub-mode called 64-bit mode, while 32-bit programs and 16-bit protected mode programs are executed in a sub-mode called compatibility mode. Real mode or virtual 8086 mode programs cannot be natively run in long mode.

<span class="mw-page-title-main">Apple–Intel architecture</span> Unofficial name used for Macintosh models that use Intel x86 processors

The Apple–Intel architecture, or Mactel, is an unofficial name used for Macintosh personal computers developed and manufactured by Apple Inc. that use Intel x86 processors, rather than the PowerPC and Motorola 68000 ("68k") series processors used in their predecessors or the ARM-based Apple silicon SoCs used in their successors. As Apple changed the architecture of its products, they changed the firmware from the Open Firmware used on PowerPC-based Macs to the Intel-designed Extensible Firmware Interface (EFI). With the change in processor architecture to x86, Macs gained the ability to boot into x86-native operating systems, while Intel VT-x brought near-native virtualization with macOS as the host OS.

<span class="mw-page-title-main">Das U-Boot</span> Open-source, primary boot the devices operating system kernel

Das U-Boot is an open-source boot loader used in embedded devices to perform various low-level hardware initialization tasks and boot the device's operating system kernel. It is available for a number of computer architectures, including M68000, ARM, Blackfin, MicroBlaze, AArch64, MIPS, Nios II, SuperH, PPC, RISC-V and x86.

<span class="mw-page-title-main">EFI system partition</span> Partition used by Unified Extensible Firmware Interface

The EFIsystem partition or ESP is a partition on a data storage device that is used by computers that have the Unified Extensible Firmware Interface (UEFI). When a computer is booted, UEFI firmware loads files stored on the ESP to start operating systems and various utilities.

In the context of free and open-source software, proprietary software only available as a binary executable is referred to as a blob or binary blob. The term usually refers to a device driver module loaded into the kernel of an open-source operating system, and is sometimes also applied to code running outside the kernel, such as system firmware images, microcode updates, or userland programs. The term blob was first used in database management systems to describe a collection of binary data stored as a single entity.

The Linux booting process involves multiple stages and is in many ways similar to the BSD and other Unix-style boot processes, from which it derives. Although the Linux booting process depends very much on the computer architecture, those architectures share similar stages and software components, including system startup, bootloader execution, loading and startup of a Linux kernel image, and execution of various startup scripts and daemons. Those are grouped into 4 steps: system startup, bootloader stage, kernel stage, and init process. When a Linux system is powered up or reset, its processor will execute a specific firmware/program for system initialization, such as the power-on self-test, invoking the reset vector to start a program at a known address in flash/ROM, then load the bootloader into RAM for later execution. In IBM PC–compatible personal computers (PCs), this firmware/program is either a BIOS or a UEFI monitor, and is stored in the mainboard. In embedded Linux systems, this firmware/program is called boot ROM. After being loaded into RAM, the bootloader will execute to load the second-stage bootloader. The second-stage bootloader will load the kernel image into memory, decompress and initialize it, and then pass control to this kernel image. The second-stage bootloader also performs several operation on the system such as system hardware check, mounting the root device, loading the necessary kernel modules, etc. Finally, the first user-space process starts, and other high-level system initializations are performed.

<span class="mw-page-title-main">ThinCan</span> Thin client manufactured in Estonia

ThinCan is a thin client manufactured by Estonian electronic design start-up Artec Group. The ThinCan remained relatively unknown outside Estonia until 2006, when a recent ThinCan iteration was selected as the hardware base for the Linutop, a network appliance that greatly stimulated the market for lightweight computing platforms. The ThinCan was also commercialized by SmartLink under the Revnetek brand name.

AMD Generic Encapsulated Software Architecture (AGESA) is a procedure library developed by Advanced Micro Devices (AMD), used to perform the Platform Initialization (PI) on mainboards using their AMD64 architecture. As part of the BIOS of such mainboards, AGESA is responsible for the initialization of the CPU cores, chipset, main memory, and the HyperTransport controller.

<span class="mw-page-title-main">SeaBIOS</span> Open-source implementation of x86 BIOS

SeaBIOS is an open-source implementation of an x86 BIOS, serving as a freely available firmware for x86 systems. Aiming for compatibility, it supports standard BIOS features and calling interfaces that are implemented by a typical proprietary x86 BIOS. SeaBIOS can either run on bare hardware as a coreboot payload, or can be used directly in emulators such as QEMU and Bochs.

In computing, a devicetree is a data structure describing the hardware components of a particular computer so that the operating system's kernel can use and manage those components, including the CPU or CPUs, the memory, the buses and the integrated peripherals.

<span class="mw-page-title-main">Libreboot</span> Coreboot distribution that uses some proprietary firmware blobs

Libreboot is a free and open-source software project based on coreboot, aimed at replacing some of the proprietary BIOS or UEFI firmware on supported X86-64- and AArch64-based computers. Libreboot performs the basic machine setup such as CPU initialization or memory controller initialization necessary to load and run a 32-bit or 64-bit operating system, such as Linux or FreeBSD.

<span class="mw-page-title-main">AMD Platform Security Processor</span> Trusted execution environment subsystem that runs on AMD microprocessors

The AMD Platform Security Processor (PSP), officially known as AMD Secure Technology, is a trusted execution environment subsystem incorporated since about 2013 into AMD microprocessors. According to an AMD developer's guide, the subsystem is "responsible for creating, monitoring and maintaining the security environment" and "its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any suspicious activity or events and implementing an appropriate response". Critics worry it can be used as a backdoor and is a security concern. AMD has denied requests to open source the code that runs on the PSP.

References

  1. Martin Roth (2 September 2024). "coreboot 24.08 release" . Retrieved 3 September 2024.
  2. "Releases". coreboot. n.d.
  3. "ARM". coreboot. 15 October 2013. Retrieved 1 February 2014.
  4. "coreboot's licence". github.com. 1991. Retrieved 13 October 2018.
  5. "[LinuxBIOS] Welcome to coreboot". 12 January 2008.
  6. Anton Borisov (2009). "The Open Source BIOS is Ten. An interview with the coreboot developers". The H . Archived from the original on 16 September 2012.'
  7. "Google Sponsors the LinuxBIOS project". Archived from the original on 6 February 2012. Retrieved 29 September 2023.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  8. "CME Group Dives Into Coreboot and Other Linux Open Source Projects". Wall Street & Technology. Archived from the original on 12 August 2010. Retrieved 23 September 2015.
  9. "Chromebooks". coreboot. 16 January 2014. Archived from the original on 8 May 2016. Retrieved 17 February 2014.
  10. "GSoC2011(Week 1): Analysis of U-boot ARM boot code | coreboot developer blogs". 5 June 2011. Retrieved 12 April 2014.
  11. "Coreboot nutzt NSA-Tool zum Reverse Engineering". Golem.de . Retrieved 4 May 2023.
  12. "Technical details on AMD's coreboot source code release". AMD. 28 February 2011. Archived from the original on 25 March 2014. Retrieved 1 February 2016.
  13. Griffith, Bruce (5 November 2014). "AMD's binary-only AGESA libraries" . Retrieved 8 May 2017.
  14. "Minifree". Ministry of Freedom - Products. Archived from the original on 25 September 2015. Retrieved 24 September 2015.
  15. "The Gluglug". fsf.org. Archived from the original on 23 September 2015. Retrieved 23 September 2015.
  16. "pcengines/coreboot". GitHub . Retrieved 16 September 2019.
  17. "coreboot Firmware on Purism Librem devices" . Retrieved 19 June 2020.
  18. "Purism Laptops To Use 'Heads' Firmware To Protect Against Rootkits, Tampering (Updated)". 27 February 2018. Retrieved 19 June 2020.
  19. "New Dasharo v1.1 Firmware For The MSI Z690 Board - Phoronix". 22 November 2022. Retrieved 27 October 2023.
  20. "NovaCustom-Dasharo October-2023 Firmware Update (ADL v1.7.0 & TGL v1.5.0) - NovaCustom". 19 September 2023. Retrieved 27 October 2023.
  21. "The NitroPC Pro is Qubes-Certified! - Nitrokey". 24 September 2023. Retrieved 27 October 2023.
  22. Starbook mk v review - fossbytes
  23. SeaBIOS (previously known as LegacyBIOS) is an open-source legacy BIOS implementation
  24. "coreboot Add-on Layer (ADLO)". Archived from the original on 25 November 2010.
  25. "SEBOS, Security Enhanced Bootloader for Operating Systems, Phase 2". Archived from the original on 19 June 2007. - adding PC BIOS Services to coreboot via Bochs BIOS
  26. "Comparison of UEFI and legacy BIOS". pronouncing that same advantage for UEFI
  27. "commit". adding that support
  28. "coreboot v3 early startup code". Archived from the original on 10 July 2012. Retrieved 17 August 2008.
  29. Yinghai Lu; Li-Ta Lo; Gregory R. Watson; Ronald G. Minnich (15 January 2009). "CAR: Using Cache as RAM in Linux BIOS" (PDF). qmqm.pl. Archived from the original (PDF) on 3 March 2016. Retrieved 25 February 2014.
  30. "A Framework for Using Processor Cache as RAM (CAR)" (PDF).
  31. Griffith, Bruce (5 November 2014). "[coreboot] AMD's binary-only AGESA libraries" . Retrieved 8 September 2019.
  32. "Sage Electronic Engineering - SmartProbe JTAG debugger, Sage EDK, coreboot and Embedded Systems and Software Engineering". www.se-eng.com. Archived from the original on 15 March 2011.{{cite web}}: CS1 maint: unfit URL (link)
  33. "Sage SmartProbe FAQ". S.Datskovskiy. Retrieved 30 April 2021.
  34. "Depthcharge: The ChromeOS bootloader". docs.google.com. Retrieved 26 October 2015.
  35. "Modify u-boot code to allow building coreboot payload. [chromiumos/third_party/u-boot-next : chromeos-v2011.03]". 24 July 2011.
  36. "Binary Blob Reduction Policy". 1 November 2023. Archived from the original on 1 November 2023. Retrieved 1 November 2023.
  37. "osboot project". 15 March 2021. Archived from the original on 15 March 2021. Retrieved 26 May 2023.
  38. "Libreboot – Osboot is now part of Libreboot". 19 December 2022. Archived from the original on 19 December 2022. Retrieved 26 May 2023.
  39. "How to install ChromeOS Flex on a Chromebook". Android Police. 17 April 2022. Retrieved 30 May 2023.
  40. "GNU Boot Summary". 30 October 2023. Archived from the original on 30 October 2023. Retrieved 30 October 2023.
  41. "Canoeboot project". 16 November 2023. Archived from the original on 16 November 2023. Retrieved 16 November 2023.
  42. "3mdeb Sp. z o.o. — Embedded Firmware development consultancy". 29 January 2024. Archived from the original on 16 February 2024. Retrieved 16 February 2024.
  43. "Dasharo • GitHub". 22 October 2023. Archived from the original on 16 February 2024. Retrieved 16 February 2024.
  44. "About Dasharo - Dasharo Universe". 9 February 2024. Archived from the original on 16 February 2024. Retrieved 16 February 2024.
  45. Kepplinger-Novakovic, Martin (28 May 2024), merge/skulls , retrieved 29 May 2024
  46. "About Heads". Heads. Retrieved 29 May 2024.
  47. linuxboot/heads, LinuxBoot, 28 May 2024, retrieved 29 May 2024

Further reading