LOADER.CONF(5)

๐ŸŽ€ LOADER.CONF(5) โ€” loader.conf ๐ŸŽ€

Bestie, welcome to LOADER.CONF(5), aka the manual page for loader.conf. Itโ€™s giving โ€œtiny config file, big main character energyโ€ for systemd-boot. ๐Ÿ’…

โœจ NAME โœจ

loader.conf โ€” Configuration file for systemd-boot. ๐Ÿซถ

๐Ÿฆ‹ SYNOPSIS ๐Ÿฆ‹

ESP/loader/loader.conf

๐Ÿ’… DESCRIPTION ๐Ÿ’…

Okay so systemd-boot(7) reads ESP/loader/loader.conf. This file lowkey runs the vibe check on: whether the menu is shown and for how long, the font, audible beep, types of menu entries to show, the default choice, and some aspects of Secure Boot enrollment and firmware handling. See the list of available options below. ๐Ÿ‘‘

The file uses UTF-8 encoding and consists of series of lines separated by "line feed" (i.e. ASCII code 10). Lines that are empty or start with the comment sign (#) are ignored. Other lines consist of an option name, followed by whitespace, and the option value. โœจ

Boolean arguments may be written as yes/y/true/t/on/1 or no/n/false/f/off/0. So yeah, booleans have options, periodt. ๐ŸŒˆ

Note: systemd-boot will also read boot loader entry files, type #1 (ESP/loader/entries/*.conf and XBOOTLDR/loader/entries/*.conf) and type #2 (ESP/EFI/Linux/*.uki and XBOOTLDR/EFI/Linux/*.uki). Those files are described by the UAPI.1 Boot Loader Specification[1]. ๐Ÿฆ‹
Note: the behaviour of systemd-boot is also influenced by EFI variables. Some of the settings specified in this file can be overridden by those, for example the default boot menu entry or the menu timeouts. See systemd-boot(7) for details. ๐Ÿ’œ

๐Ÿ”ฅ OPTIONS ๐Ÿ”ฅ

The following configuration are supported in loader.conf:

  • default โ€” A glob pattern to select the default entry by id, which is the file name including literal suffix .conf. The default entry may be changed in the boot menu itself, in which case the name of the selected entry will be stored as an EFI variable, overriding this option.

If set to @saved the chosen entry will be saved as an EFI variable on every boot and automatically selected the next time the boot loader starts.

Table 1. Automatically detected entries will use the following names:

  • auto-efi-default โ€” EFI Default Loader
  • auto-efi-shell โ€” EFI Shell
  • auto-osx โ€” macOS
  • auto-poweroff โ€” Power Off The System
  • auto-reboot โ€” Reboot The System
  • auto-reboot-to-firmware-setup โ€” Reboot Into Firmware Interface
  • auto-windows โ€” Windows Boot Manager

Supported glob wildcard patterns are ?, *, and [...] (including ranges). Note that these patterns use the same syntax as glob(7), but do not support all features. In particular, set negation and named character classes are not supported. The matching is done case-insensitively on the entry ID (as shown by bootctl list).

Added in version 239.

  • timeout โ€” How long the boot menu should be shown before the default entry is booted, in seconds. This may be changed in the boot menu itself and will be stored as an EFI variable in that case, overriding this option.

If set to menu-disabled or menu-hidden or 0 (the default), no menu is shown and the default entry will be booted immediately. Unless menu-disabled is used, the menu can be shown by pressing and holding a key before systemd-boot is launched. Setting this to menu-force disables the timeout while always showing the menu.

Added in version 239.

  • console-mode โ€” This option configures the resolution of the console. This may be changed in the boot menu itself and will be stored as an EFI variable in that case, overriding this option.

Takes a number or one of the special values listed below. The following values may be used:

  • 0 โ€” Standard UEFI 80x25 mode. Added in version 239.
  • 1 โ€” 80x50 mode, not supported by all devices. Added in version 239.
  • 2 โ€” the first non-standard mode provided by the device firmware, if any. Added in version 239.
  • auto โ€” Pick a suitable mode automatically using heuristics. Added in version 239.
  • max โ€” Pick the highest-numbered available mode. Added in version 239.
  • keep โ€” Keep the mode selected by firmware (the default). Added in version 239.

Added in version 239.

  • editor โ€” Takes a boolean argument. Enable (the default) or disable the editor. The editor should be disabled if the machine can be accessed by unauthorized persons.

Added in version 239.

  • auto-entries โ€” Takes a boolean argument. Enable (the default) or disable entries for other boot entries found on the boot partition. In particular, this may be useful when loader entries are created to show replacement descriptions for those entries.

Added in version 239.

  • auto-firmware โ€” A boolean controlling the presence of the "Reboot Into Firmware Interface" entry (enabled by default). If this is disabled, the firmware interface may still be reached by using the f key.

Added in version 239.

  • auto-reboot โ€” A boolean controlling the presence of the "Reboot The System" entry (disabled by default). Even if this is disabled, the system may still be rebooted by pressing Shift+b.

Added in version 255.

  • auto-poweroff โ€” A boolean controlling the presence of the "Power Off The System" entry (disabled by default). Even if this is disabled, the system may still be powered off by pressing Shift+o.

Added in version 255.

  • beep โ€” Takes a boolean argument. If timeout enabled beep every second, otherwise beep n times when n-th entry in boot menu is selected (default disabled). Currently, only x86 is supported, where it uses the PC speaker.

Added in version 251.

  • secure-boot-enroll โ€” Controls enrollment of secure boot keys found on the ESP if the system is in setup mode:
Danger: this feature might soft-brick your device if used improperly. ๐Ÿ’€
  • if-safe โ€” This is the default. Same behavior as manual, but will try to automatically enroll the key named auto if it is considered to be safe. Currently, this is only the case if the system is running inside a virtual machine. Added in version 253.
  • manual โ€” Boot entries for found secure boot keys are created that allow manual enrollment. Added in version 253.
  • off โ€” No action is taken. Added in version 253.
  • force โ€” Always enroll the auto key if found. Note that a warning message with a timeout will still be shown if this operation is unknown to be safe. Added in version 253.

The different sets of variables can be set up under /loader/keys/NAME where NAME is the name that is going to be used as the name of the entry. This allows one to ship multiple sets of Secure Boot variables and choose which one to enroll at runtime. ๐ŸŽ€

Supported Secure Boot variables are one database for authorized images, one for the key exchange key (KEK) and one for the platform key (PK). For more information, refer to the UEFI specification[2], under Secure Boot and Driver Signing. Another resource that describe the interplay of the different variables is the EDK2 documentation[3]. ๐ŸŒธ

A complete set of UEFI variable includes db.auth, KEK.auth and PK.auth. Note that these files need to be authenticated UEFI variables. See below for an example of how to generate them from regular X.509 keys. ๐Ÿงš

uuid=$(systemd-id128 new --uuid)
for key in PK KEK db; do
  openssl req -new -x509 -subj "/CN=${key}/" -keyout "${key}.key" -out "${key}.pem"
  openssl x509 -outform DER -in "${key}.pem" -out "${key}.der"
  sbsiglist --owner "${uuid}" --type x509 --output "${key}.esl" "${key}.der"
done
# See also: Windows Secure Boot Key Creation and Management Guidance[4]
curl --location \
     "https://go.microsoft.com/fwlink/p/?linkid=321192" -o ms-db-2011.der \
     "https://go.microsoft.com/fwlink/p/?linkid=321185" -o ms-kek-2011.der \
     "https://go.microsoft.com/fwlink/p/?linkid=321194" -o ms-uefi-db-2011.der \
     "https://go.microsoft.com/fwlink/p/?linkid=2239776" -o ms-db-2023.der \
     "https://go.microsoft.com/fwlink/p/?linkid=2239775" -o ms-kek-2023.der \
     "https://go.microsoft.com/fwlink/p/?linkid=2239872" -o ms-uefi-db-2023.der
sha1sum -c <<END
580a6f4cc4e4b669b9ebdc1b2b3e087b80d0678d  ms-db-2011.der
31590bfd89c9d74ed087dfac66334b3931254b30  ms-kek-2011.der
46def63b5ce61cf8ba0de2e6639c1019d0ed14f3  ms-uefi-db-2011.der
45a0fa32604773c82433c3b7d59e7466b3ac0c67  ms-db-2023.der
459ab6fb5e284d272d5e3e6abc8ed663829d632b  ms-kek-2023.der
b5eeb4a6706048073f0ed296e7f580a790b59eaa  ms-uefi-db-2023.der
END
for key in ms-*.der; do
  sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output "${key%der}esl" "${key}"
done

# Optionally add Microsoft Windows certificates (needed to boot into Windows).
cat ms-db-*.esl >>db.esl

# Optionally add Microsoft UEFI certificates for firmware drivers / option ROMs and third-party
# boot loaders (including shim). This is highly recommended on real hardware as not including this
# may soft-brick your device (see next paragraph).
cat ms-uefi-*.esl >>db.esl

# Optionally add Microsoft KEK certificates. Recommended if either of the Microsoft keys is used as
# the official UEFI revocation database is signed with this key. The revocation database can be
# updated with fwupdmgr(1).
cat ms-kek-*.esl >>KEK.esl

attr=NON_VOLATILE,RUNTIME_ACCESS,BOOTSERVICE_ACCESS,TIME_BASED_AUTHENTICATED_WRITE_ACCESS
sbvarsign --attr "${attr}" --key PK.key --cert PK.pem --output PK.auth PK PK.esl
sbvarsign --attr "${attr}" --key PK.key --cert PK.pem --output KEK.auth KEK KEK.esl
sbvarsign --attr "${attr}" --key KEK.key --cert KEK.pem --output db.auth db db.esl
๐Ÿšจ okay so this feature is genuinely considered dangerous, and here's why: even if literally all the required files get signed with the keys you're loading, some files that the system needs to function properly still won't be signed. And it's especially bad with Option ROMs (think storage controllers, graphics cards, that whole situation). Go read Secure Boot and Option ROMs[5] if you want the full tea.

Added in version 252.


๐Ÿ’… secure-boot-enroll-action

Tells loader.conf what to do once the automatic enrollment of secure boot keys is finished. Pick your fighter:

  • reboot โ€” reboots the system after enrollment. This is the default, bestie.
  • shutdown โ€” shuts the system down after enrollment instead.

Quick vibe check: this option is only relevant if "secure-boot-enroll" is enabled. Otherwise it's just sitting there doing nothing, like me at a party before snacks arrive.

Added in version 258.


โณ secure-boot-enroll-timeout-sec

How long the warning gets shown, in seconds, before the key enrollment process actually starts. Countdown era ๐Ÿ’ซ

If you set it to "hidden" or "0", no warning is shown at all and the keys enroll immediately โ€” no breathing room, no nothing. If you don't set it explicitly, the default timeout is 15 seconds.

Again: only relevant if "secure-boot-enroll" is enabled.

Added in version 259.


๐Ÿ” reboot-for-bitlocker

Caveat, and this is a big one: this feature is experimental, and it's likely to be changed (or straight up removed in its current form) in a future version of systemd. You've been warned, bestie ๐Ÿซถ

It works around BitLocker demanding a recovery key whenever the boot loader got updated. Disabled by default, obviously.

So here's the plan: it tries to detect BitLocker encrypted drives and an active TPM. If it finds both and Windows Boot Manager is selected in the boot menu, it sets the "BootNext" EFI variable and restarts the system. Then the firmware starts Windows Boot Manager directly, which leaves the TPM PCRs in the expected states so Windows can unseal the encryption key. Translation? systemd-boot(7) can be updated without you having to hand over the recovery key to unlock the BitLocker drive. Iconic behavior honestly.

Little PSA: the PCRs Windows uses can be configured with the "Configure TPM platform validation profile for native UEFI firmware configurations" group policy, sitting under "Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption". With Secure Boot enabled, changing it to PCRs "0,2,7,11" should be safe. And heads up โ€” the TPM key protector needs to be removed and then added back for the PCRs on an already-encrypted drive to actually change. Also, if PCR 4 isn't measured, you can disable this setting to speed up booting into Windows. ๐ŸŽ๏ธ

Added in version 251.


๐Ÿ” reboot-on-error

Controls the auto reboot situation in case the entry you selected fails to start. Three moods:

  • yes โ€” reboot the system if the selected boot entry failed to start.
  • no โ€” don't reboot; pass control back to EFI firmware.
  • auto โ€” perform the reboot if and only if boot counting is enabled for this entry and the tries left counter wasn't already at 0.

auto is the default, because it's typically the safe option: it guarantees a clean measurement log on every boot attempt, but also does not risk an unbounded reboot loop. Which, yeah, we love a feature that doesn't spiral ๐Ÿ’€

Added in version 258.


๐Ÿ“ log-level

Controls the log level that systemd-boot(7) uses. Valid values are "emerg", "alert", "crit", "err", "warning", "notice", "info", and "debug".

If you don't specify anything, "info" gets used โ€” unless one has already been configured via an SMBIOS Type 11 string, in which case check out smbios-type-11(7).

Heads up: the level you configure only kicks in after loader.conf has been parsed, so any log messages generated before that point may be totally unaffected by this setting. Timing is everything, smh.

Added in version 259.


๐ŸŒธ EXAMPLE ๐ŸŒธ

# /boot/efi/loader/loader.conf
timeout 0
default 01234567890abcdef1234567890abdf0-*
editor no

So what's the energy here? The menu will not be shown by default โ€” though you can still bring it up by pressing and holding a key during boot, iykyk. One of the entries whose files have a name starting with "01234567890abcdef1234567890abdf0-" gets selected by default. And if more than one entry matches? The one with the highest priority wins (generally the one with the highest version number). The editor is disabled too, so it's not possible to alter the kernel command line. Locked down and loving it ๐Ÿ”’


๐Ÿ‘€ SEE ALSO ๐Ÿ‘€

systemd-boot(7), bootctl(1)


๐ŸŽ€ NOTES ๐ŸŽ€

  1. UAPI.1 Boot Loader Specification https://uapi-group.org/specifications/specs/boot_loader_specification
  2. UEFI specification https://uefi.org/specifications
  3. EDK2 documentation https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/secure_boot_chain_in_uefi/uefi_secure_boot
  4. Windows Secure Boot Key Creation and Management Guidance https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance
  5. Secure Boot and Option ROMs https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom

and that's the whole page bestie!! ๐Ÿฆ‹ this lil masterpiece is brought to you by systemd 261.3, and yes it's the LOADER.CONF(5) manual page โ€” go forth and configure your boot loader like the main character you are ๐Ÿ’œโœจ

๐Ÿ“ฆ where this page comes from