src/boot/efi/UEFI_SECURITY.md

   1 # UEFI Components Security Posture
   2 The systemd project provides a UEFI boot menu, `systemd-boot`, and a stub that can wrap a Linux kernel in a
   3 PE binary, adding various features, `systemd-stub`. These components fully support UEFI SecureBoot, and
   4 this document will describe their security posture and how they comply with industry-standard expectations
   5 for UEFI SecureBoot workflows.
   6
   7 Note that `systemd-stub` is not the same, or an alternative, to the Linux kernel's own EFI stub. The kernel
   8 stub's role is that of the fundamental entrypoint to kernel execution from UEFI mode, implementing the
   9 modern Linux boot protocol. `systemd-stub` on the other hand loads various resources, including the kernel
  10 image, via the EFI LoadImage/StartImage protocol (although it does support the legacy Linux boot protocol,
  11 as a fallback for older kernels on x86). The purpose of `systemd-stub` is to provide additional features and
  12 functionality for either or both `systemd-boot` and `systemd` (userspace).
  13
  14 ## Fundamental Security Design Goals
  15 The fundamental security design goals for these components are separation of security policy logic from the
  16 rest of the functionality, achieved by offloading security-critical tasks to the firmware or earlier stages
  17 of the boot process (e.g.: `Shim`).
  18
  19 When SecureBoot is enabled, these components are designed to avoid executing, loading or using
  20 unauthenticated payloads that could compromise the boot process, with special care taken for anything that
  21 could affect the system before `ExitBootServices()` has been called. For example, when additional resources
  22 are loaded, if running with SecureBoot enabled, they will be validated before use. The only exceptions are
  23 the bootloader's own textual configuration files, and parsing metadata out of images for displaying purposes
  24 only. There are no build time or runtime configuration options that can be set to weaken the security model
  25 of these components when SecureBoot is enabled.
  26
  27 The role of `systemd-boot` is to discover next stage components in the ESP (and XBOOTLDR if present), via
  28 filesystem enumeration or explicit configuration files, and present a menu to the user, to choose the next
  29 step. This auto discovery mechanism is described in details in the [BLS (Boot Loader
  30 Specification)](https://uapi-group.org/specifications/specs/boot_loader_specification/).
  31
  32 The role of `systemd-stub` is to load and measure in the TPM the post-bootloader stages, such as the kernel,
  33 initrd and kernel command line, and implement optional features such as augmenting the initrd with
  34 additional content such as configuration or optional services. [Unified Kernel
  35 Images](https://uapi-group.org/specifications/specs/unified_kernel_image/) embed `systemd-stub`, a kernel
  36 and other optional components as sections in a PE signed binary, that can thus be executed in UEFI
  37 environments.
  38
  39 Since it is embedded in a PE signed binary, `systemd-stub` will temporarily disable the UEFI authentication
  40 protocol while loading the payload kernel it wraps, in order to avoid redundant duplicate authentication of
  41 the image, given that the payload kernel was already authenticated and verified as part of the whole image.
  42 SecureBoot authentication is re-enabled immediately after the kernel image has been loaded.
  43
  44 Various EFI variables, under the vendor UUID `4a67b082-0a4c-41cf-b6c7-440b29bb8c4f`, are set and read by
  45 these components, to pass metadata and configuration between different stages of the boot process, as
  46 defined in the [Boot Loader Interface](https://systemd.io/BOOT_LOADER_INTERFACE/).
  47
  48 ## Dependencies
  49 Neither of these components implements cryptographic primitives, cryptographic checks or drivers. File
  50 access to the ESP is implemented solely via the appropriate UEFI file protocols. Verification of next stage
  51 payloads is implementend solely via the appropriate UEFI image load protocols, which means authenticode
  52 signature checks are again done by the firmware or `Shim`. As a consequence, no external security-critical
  53 libraries (such as OpenSSL or gnu-efi) are used, linked or embedded.
  54
  55 ## Additional Resources
  56 BLS Type #1 entries allow the user to load two types of additional resources that can affect the system
  57 before `ExitBootServices()` has been called, kernel command line arguments and Devicetree blobs, that are
  58 not validated before use, as they do not carry signatures. For this reason, when SecureBoot is enabled,
  59 loading these resources is automatically disabled. There is no override for this security mechanism, neither
  60 at build time nor at runtime. Note that initrds are also not verified in BLS Type #1 configurations, for
  61 compatibility with how SecureBoot has been traditionally handled on Linux-based OSes, as the kernel will
  62 only load them after `ExitBootServices()` has been called.
  63
  64 Another mechanism is supported by `systemd-boot` and `systemd-stub` to add additional payloads to the boot
  65 process: `addons`. Addons are PE signed binaries that can carry kernel command line arguments or Devicetree
  66 blobs (more might be added in the future). In contrast to the user-specified additions in the Type #1 case
  67 described above, these addons are loaded through the UEFI image loading protocol, and thus are subject to
  68 signature validation, and will be rejected if not signed or if the signature is invalid, following the
  69 standard SecureBoot model. They are also measured in the TPM.
  70
  71 `systemd-boot` will also load file system drivers that are stored in the ESP, to allow enhancing the
  72 firmware's capabilities. These are again PE signed binaries and will be verified using the appropriate
  73 UEFI protocol.
  74
  75 A random seed will be loaded and passed to the kernel for early-boot entropy pool filling if found in the
  76 ESP. It is mixed with various other sources of entropy available in the UEFI environment, such as the RNG
  77 protocol, the boot counter and the clock. Moreover, the seed is updated before the kernel is invoked, as
  78 well as after the kernel is invoked (from userspace), with a new seed derived from the Linux kernel entropy
  79 pool.
  80
  81 When operating as a virtual machine payload, the loaded payloads can be customized via `SMBIOS Type 11
  82 Strings`, if the hypervisor specifies them. This is automatically disabled if running inside a confidential
  83 computing VM.
  84
  85 ## Certificates Enrollment
  86 When SecureBoot is supported but in `setup` mode, `systemd-boot` can enroll user certificates if a set of
  87 `PK`, `KEK` and `db` certificates is found in the ESP, after which SecureBoot is enabled and a firmware
  88 reset is performed. When running on bare metal, the certificate(s) will be shown to the user on the console,
  89 and manual confirmation will be asked before proceeding. When running as a virtual machine payload,
  90 enrollment is fully automated, without user interaction, unless disabled via a configuration file in the
  91 ESP. The configuration file can also be used to disable enrollment completely.
  92
  93 ## Compiler Hardening
  94 The PE binaries are built with `-fstack-protector-strong`, and the stack canary is seeded with random data if
  95 the UEFI RNG protocol is available.
  96
  97 The binaries also are linked with `-z relro` and ship with native PE relocations, with the conversion from
  98 ELF performed at build time, instead of containing ELF dynamic relocations, so the image loaded by
  99 firmware/Shim requires fewer writable pages.
 100
 101 The binaries are linked by default with full LTO support, so no code will be shipped unless it's reachable.
 102
 103 Finally, the binaries ship with the `NX_COMPAT` bit set.
 104
 105 The CI infrastructure also employs fuzz testing on various components, including string functions and the
 106 BCD parser.
 107
 108 ## SBAT
 109 `systemd-boot` and `systemd-stub` are built with an `SBAT` section by default. There are build options to
 110 allow customizations of the metadata included in the section, that can be used by downstream distributors.
 111 The `systemd` project will participate in the coordinated `SBAT` disclosure and metadata revision process as
 112 deemed necessary, in coordination with the Shim Review group.
 113
 114 The upstream project name used to be unified (`systemd`) for both components, but since version v255 has
 115 been split into separate `systemd-boot` and `systemd-stub` project names, so that each component can be
 116 revisioned independently. Most of the code tend to be shared between these two components, but there is no
 117 complete overlap, so it is possible for a vulnerability to affect only one component but not the other.
 118
 119 ## Known Vulnerabilities
 120 There is currently one known (and fixed) security vulnerability affecting `systemd-boot` on arm64 and
 121 riscv64 systems. For details of the affected and fixed versions, please see the [published security
 122 advisory.](https://github.com/systemd/systemd/security/advisories/GHSA-6m6p-rjcq-334c)