Change log_internal() to receive a log level from which a text color is
derived, rather than the text color directly, and adjust various log_*
macros to use them internally.
"path" sounds like a fully qualified complete string referencing some
terminal object. But here it's not like that, the field just stores the
directory the object we actually care about is placed in. Hence let's
change this field to be named "directory", to be less confusing for
readers.
Commit 70b7e03 introduced 3 calls to log_debug() about the presence or
absence of NX_COMPAT support. Since sd-boot does not yet have the
ability to only print messages above a certain loglevel, these will
always be printed, even on top of the configured splash screen. This
commit removes the log_debug() call after a success and only prints
those for missing firmware support if the UEFI should support them in
the first place (i.e. starting with version 2.10).
When NX_COMPAT gets enabled, firmwares will enforce that executable
memory is either writable or executable.
This needs kernel compatibility, when it will happen the kernel will
have the NX_COMPAT bit set. If it is, set the memory buffer to RO.
Note that this must be undone on failure, as EDK2 in some configurations
overwrites memory ranges that are returned with FreePages() with a
fixed pattern, so if the pages are RO it will crash.
This is only an issue with the new custom PE loader, as LoadImage()
and StartImage() will always do the right thing automatically.
https://microsoft.github.io/mu/WhatAndWhy/enhancedmemoryprotection/https://www.kraxel.org/blog/2023/12/uefi-nx-linux-boot/
Follow-up for cab9c7b5a4
Fixes https://github.com/systemd/systemd/issues/38545
Fedora's kernels now ship with a .sbat section:
kernel,1,Red Hat,kernel-core,6.17.0-0.rc1.250814g0cc53520e68b.20.fc44.x86_64,mailto:secalert@redhat.com
kernel.fedora,1,Red Hat,kernel-core,6.17.0-0.rc1.250814g0cc53520e68b.20.fc44.x86_64,mailto:secalert@redhat.com
This pushes the combined .sbat section just over its pre-allocated size of 512 bytes:
File "/usr/bin/ukify", line 1048, in pe_add_sections
raise PEError(f'Not enough space in existing section {section.name} to append new data')
PEError: Not enough space in existing section .sbat to append new data
PE sections need to align to 512 bytes, so to make it all fit we pad the .sbat
section with zeros to 1k. Various tools already should strip trailing zeros when
using sbat sections, since ukify always inserts a trailing NUL.
The defines are moved to sbat.h, they are used only in sd-stub and sd-boot.
- Reuse parent_image instead of allocating new ones. Firmware might cast
EFI_LOADED_IMAGE_PROTOCOL * to a larger struct causing issues
- Remove loaded image protocol installation and uninstallation which are no
longer required
Fixes a bug introduced by cab9c7b5a4.
Fixes#38567.
Co-authored-by: Tobias Heider <tobias.heider@canonical.com>
It is extremely confusing to use different filenames for different
locations, so pick up the same images for both per-UKI and global
extensions
Follow-up for 9f7e3820e9
We went back and forth between 'prog.sh', files('prog.sh'), and
find_program('prog.sh'). We want to use files() or find_program() so that we
get a good error message if the file is missing. Behaviour of meson changed
over time, and in the past not all forms could be used in all places. For
example 0f4c4f3824 added find_program() in many
places to avoid repeated messages. But it seems that all recent meson versions
work fine with files().
find_program prints silly messages:
Program tools/make-man-index.py found: YES
(/home/zbyszek/src/systemd/tools/make-man-index.py)
Program tools/meson-render-jinja2.py found: YES
(/home/zbyszek/src/systemd/tools/meson-render-jinja2.py)
...
We know that those files will be found, they are part of the git checkout.
With files() this is gone and the meson output is easier to read.
All those files are standalone programs that can be executed directly.
Some .py files were marked executable, others weren't, probably accidentally.
Mark them all as executable in preparation for subsequent changes.
It is possible to boot directly a UKI from shim, and Fedora Cloud Base UKI
does exactly this.
This used to work fine until https://github.com/systemd/systemd/pull/37372
which broke compatibility when shim < 16.0 (no loader protocol override) is
used. Shim 15.8 is still in use in several distributions, and will be for
a long time.
Restore a part of the previous implementation, and if running with secure
boot enabled, and with shim but < 16.0, apply a security override.
Follow-up for cab9c7b5a4
Fixes https://github.com/systemd/systemd/issues/38104
The comment in linux_exec() was based on Lennart's comment in
https://github.com/systemd/systemd/pull/37372#discussion_r2142340582, but
shortened. The original wording is more direct and at least for me easier to
grok, so adjust the comment to be more verbose again.
Also, move the comment from shim_loader_available() to the place where it used.
This function is for checking if the new thing is available, no need to describe
the old thing there.
It turns out checking sysfs is not 100% reliable to figure out whether
the firmware had TPM2 support enabled or not. For example with EDK2 arm64, the
default upstream build config bundles TPM2 support with SecureBoot support,
so if the latter is disabled, TPM2 is also unavailable. But still, the ACPI
TPM2 table is created just as if it was enabled. So /sys/firmware/acpi/tables/TPM2
exists and looks correct, but there are no measurements, neither the firmware
nor the loader/stub can do them, and /sys/kernel/security/tpm0/binary_bios_measurements
does not exist.
The loader can use the apposite UEFI protocol to check, which is a more
definitive answer. Given userspace can also make use of this information, export
the bitmask with the list of active banks as-is. If it's not 0, then we can be
sure a working TPM2 was available in EFI mode.
Partially fixes https://github.com/systemd/systemd/issues/38071
Systemd-stub support loading addons, credentials, system and configuration
extensions from ESP and while addons and credentials can be both global and
per-UKI, sysext/confext are only per-UKI.
Add support for loading ESP/loader/credentials/*.{sysext,confext}.raw to
systemd-stub.
Note: for backwards compatibility reasons, per-UKI sysexts can also be
*.raw (not only *.sysext.raw) but as global extensions are new, there's
no need to bring this legacy there.
[1] says:
> Since 0.60.0 the name argument is optional and defaults to the basename of
> the first output
We specify >= 0.62 as the supported version, so drop the duplicate name in all cases
where it is the same as outputs[0], i.e. almost all cases.
[1] https://mesonbuild.com/Reference-manual_functions.html#custom_target
We correctly handle invalid timeouts being stored in EFI variables, but
because we deal with this gracefully we should downgrade the log level
to warning, and say "ignoring" in the log message.
Inspired by #34084
So far we already had a logic in place to go for the next mode if some
mode doesn't work – but it was only applied if we'd actively cycle
through resolutions.
Let's extend the logic and always apply it: whenever we try to switch to
a mode, and it doesn't work, go to the next one until we find one that
works.
Fixes: #37324
Since shim 16, it is not possible anymore to override the security arch
protocol to avoid signature check and measurements.
Also on Dell servers, EFI_SECURITY2_ARCH_PROTOCOL is not implemented, so
unexpected measurements on PCR 4 were still happening.
This just loads and run the kernel pe. We verify that there is no relocation
needed. Also for simplification, we assume and verify that the base address is
expected to be 0.
Instead of using run-clang-tidy.py with its own scheduling, let's
just gather a list of source files ourselves and then use that to
add a unit test for each source file that runs clang-tidy on the
source file.
We also add a bit of logic to run clang-tidy on most header files
as well for extra coverage. This uncovered various header files that
were not standalone so this commit also includes fixes to make sure
the clang-tidy tests are all green.
We can also use this in a later commit to run clang-include-cleaner
on each source file in the same way.
Let's ensure all of our source file names are unique without having
to take the directory into account.
This allows us to create meson targets or unit tests identified by the
the name of the source file they operate on without having to include
the full path of the source file in the target or test name to avoid
conflicts.
Add support for a sysfail boot entry. Sysfail boot entries can be used
for optional tweaking the automatic selection order in case a failure
state of the system in some form is detected (boot firmware failure
etc).
The EFI variable `LoaderEntrySysFail` contains the sysfail boot loader
entry to use. It can be set using bootctl:
```
$ bootctl set-sysfail sysfail.conf
```
The `LoaderEntrySysFail` EFI variable would be unset automatically
during next boot by `systemd-boot-clear-sysfail.service` if no system
failure occured, otherwise it would be kept as it is and a system
failure reason will be saved to `LoaderSysFailReason` EFI variable.
`sysfail_check()` expected to be extented to support possibleconditions
when we should boot sysfail("recovery") boot entry.
Also add support for using a sysfail boot entry in case of UEFI firmware
capsule update failure [1]. The status of a firmware update is obtained
from the EFI System Resource Table (ESRT), which provides an optional
mechanism for identifying device and system firmware resources for the
purposes of targeting firmware updates to those resources.
Current implementation uses the value of LastAttemptStatus field from
ESRT, which describes the result of the last firmware update attempt for
the firmware resource entry. The field is updated each time an
`UpdateCapsule()` is attempted for an ESRT entry and is preserved across
reboots (non-volatile).
This can be be used in setups with support for A/B OTA updates, where
the boot firmware and Linux/RootFS might be updated synchronously.
The check is activated by adding "sysfail-firmware-upd" to loader.conf
[1]
https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.html
Add support for using a sysfail boot entry in case of UEFI firmware
capsule update failure [1]. The status of a firmware update is obtained from
the EFI System Resource Table (ESRT), which provides an optional mechanism
for identifying device and system firmware resources for the purposes of
targeting firmware updates to those resources.
Current implementation uses the value of LastAttemptStatus field from
ESRT, which describes the result of the last firmware update attempt for
the firmware resource entry. The field is updated each time an
UpdateCapsule() is attempted for an ESRT entry and is preserved across
reboots (non-volatile).
This can be be used in setups with support for A/B OTA updates, where
the boot firmware and Linux/RootFS might be updated synchronously.
[1] https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.html
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>