151 lines
4.3 KiB
ReStructuredText
151 lines
4.3 KiB
ReStructuredText
******************
|
|
Boot Flow Overview
|
|
******************
|
|
|
|
To ease the support and developement of CoreOS on multiple plateform,
|
|
we use the same boot flow mechanisums on all our supported machine.
|
|
|
|
Glossary
|
|
========
|
|
|
|
In this document, the following terms have specific meanings:
|
|
|
|
.. glossary::
|
|
|
|
Firmware
|
|
Program that implement some of the boot and runtime services defined by
|
|
the :ext+uefi:ref:`UEFI specifications <maincontent>`.
|
|
|
|
Application
|
|
Program written according to the UEFI specification that can be started
|
|
by the firmware. See :ext:ref:`UEFI Applications <uefi-applications>`.
|
|
|
|
Bootloader
|
|
Application that allow to start other application based on user selection,
|
|
configuration or autodetection.
|
|
|
|
Operating system
|
|
Application that include at least the Linux Kernel.
|
|
|
|
Unified Kernel Image
|
|
Application that include the Linux kernel and the command line to pass to
|
|
the kernel and optionaly one or more device trees and a RAM disk
|
|
|
|
|
|
Generic Boot Flow
|
|
=================
|
|
|
|
.. uml:: bootflow-generic.plantuml
|
|
|
|
CoreOS use a standardized workflow based on UEFI: the firmware automatically
|
|
start the bootloader. The bootloader is stored inside the EFI partition, under:
|
|
`/EFI/BOOT/BOOT<ARCH>.EFI` where `<ARCH>` is:
|
|
|
|
- ARM for Arm32 CPU
|
|
- A64 for Aarch64 CPU
|
|
- X64 for Amd64 CPU
|
|
|
|
|
|
Firmware
|
|
========
|
|
|
|
CoreOS support two different use case:
|
|
|
|
Using a CoreOS provided firmware
|
|
--------------------------------
|
|
|
|
The most common use case is to use a firmware image provided by CoreOS as part
|
|
of the board support package.
|
|
|
|
Currently, the CoreOS provided firmware functionality is provided by `u-boot`
|
|
|
|
Using CoreOS on third party machine
|
|
-----------------------------------
|
|
|
|
As the interface between the firmware and the rest of the system is clearly
|
|
defined, we also support to run CoreOS on top of any standard UEFI complient
|
|
system.
|
|
|
|
As an example, this is the case when using a CoreOS image inside a virtual
|
|
machine.
|
|
|
|
Firmware requirements
|
|
---------------------
|
|
|
|
|
|
ARM32 / AArch32 based machine
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The firmware for ARM32 should implement a subset of the UEFI specification, as
|
|
defined by the EBBR Specification. As this architecure is used on old hardware,
|
|
it's ok to use the part of the specification that are marked as deprecated or
|
|
legacy like:
|
|
|
|
- MBR partitionning instead of GPT
|
|
- Fixed offsets to firmware data
|
|
|
|
We require the firmware to provide a DeviceTree based system description and not
|
|
an ACPI based table (as allowed by the specification)
|
|
|
|
We also require the firmware to implement the UEFI Secure Boot functionality.
|
|
|
|
ARM64 / AArch64 based machine
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The firmware for ARM64 should implement a subset of the UEFI specification, as
|
|
defined by the EBBR Specification. The part of the specification marked as
|
|
legacy or deprecated must not be used.
|
|
|
|
This means:
|
|
|
|
- Only GPT partionning disk are supported
|
|
- No fixed offsets to firmware data
|
|
|
|
We require the firmware to provide a DeviceTree based system description and not
|
|
an ACPI based table (as allowed by the specification)
|
|
|
|
We also require the firmware to implement the UEFI Secure Boot functionality.
|
|
|
|
|
|
AMD64 / x86_64 based machine
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The firmware for AMD64 should implement the UEFI specification.
|
|
|
|
Bootloader
|
|
==========
|
|
|
|
CoreOS only support `efibootguard` as bootloader.
|
|
|
|
|
|
Operating system
|
|
================
|
|
|
|
The operating system image is an UEFI application that contain the kernel.
|
|
|
|
Two ways can be used to generate this application:
|
|
|
|
Kernel built with the built-in EFI stub
|
|
---------------------------------------
|
|
|
|
This method use the EFI stub provided by the kernel.
|
|
|
|
|
|
Unified Kernel Images (UKI)
|
|
---------------------------
|
|
|
|
This is the most secure method. The UEFI entry point is provided by
|
|
`efibootguard/stub` and the image contains the Linux Kernel with it's built-in
|
|
EFI stub, the boot arguments of the kernel and optionaly multiple device trees
|
|
and an initial RAM disk.
|
|
|
|
This allows to have all these part authenticated via UEFI secure boot just by
|
|
signing the UKI.
|
|
|
|
.. important::
|
|
|
|
Only the Unified Kernel Image methods is supported by the CoreOS teams. Using
|
|
the kernel directly should be used only for new hardware bring-up. By default
|
|
we only sign UKI to ensure that it's the only method used for hardware that
|
|
ship with secure boot enabled.
|