This can lead to booting with a completely garbled command line with characters
being interpreted as miscellaneous CJK or symbols.
According to the UEFI spec, the optional data of the load option is just a
binary data buffer.
When using canary check with "-fstack-protector-all" option. It causes a configure
error in systemd-boot when meson.build executes compile simple code to test linker option
"-static-pie" because -nolibstd option prevents using libc. It need for
canary to provide some function as "__stack_chk_guard". So need to turn off
canary check when compile sanity check.
Commit e2a3d56218 added the `uki` option
to sd-boot, and 1e9c9773b9 added
`profile`, but because these were not added in src/shared/bootspec,
bootctl still shows warnings like `Unknown line 'uki', ignoring.` when
parsing the config. This PR allows parsing and displaying them correctly
in `bootctl` output. It also stops it from printing a warning for any of
the new `loader.conf` options (`log-level`, `reboot-on-error`, etc.).
Note that `uki-url` is still not handled as I can't easily test it.
Those were added before 0.61 which is our minimum version.
Dots were dropped from the end of some messages. Most messages did not have the
trailing dot.
0.63 added support for multi-line f-strings. We can't use those yet.
This allows Type 1 entries to take advantage of multiprofile efi files
by allowing the configuration of the profile associated with that entry.
It will now parse the profile key in a Type 1 config to select that
profile when booting that efi file instead of relaying in the cmdline
Signed-off-by: Itxaka <itxaka@kairos.io>
let's place the cursor at the beginning of the line before/after, so we
know it's the first char we overwrite, and we return to the front again
right after.
So, UEFI's color texting is a bit weird. It translates everything to
ANSI sequences, but unlike ANSI sequences it has no understanding of a
distinct "default" bg/fg color, it assumes the ansi color "0" is always
equal to white on black, but that's of course not really true, most
terminal emulators at the very least support white background too.
tianocore then also tries to be smart and suppresses ANSI color changes
from a color to itself. But if the understanding of the color is wrong
in the first place, then any color change suppression like this hurts
more than it helps.
Then in addition there are certain terminal tools that will reset the bg
color on every line break ("less" for example) to the default.
Let's deal with that and improve the situation on all fronts:
1. force out color changes by doing two color changes whenever we really
want it.
2. on every newline force out the color change again.
with this in place, using sd-boot on a terminal emulator is a lot nicer.
This also drops space between number and 's', like we do in format_timespan(),
and fixes spurious type mismatch between timeout_sec and timeout_remain.
Let's never bother with old TPM 1.x structures, they are not mentioned
in the TCG for TPM2 spec at all. However, the spec does say we should
check the Size field of the relevant structs, before accessing them,
hence do that.
Currently, a 15-second timeout is hardcoded for the key enrollment
process while waiting for user confirmation. Make this value configurable
to allow the option of disabling user input, such as during automatic key
provisioning at the factory.
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
This allows for more liberal usage of logging functionality as messages
will no longer always show up on screen, regardless of urgency. The log
level to use can be configured through an SMBIOS type 11 string
(`io.systemd.boot.loglevel=`) or by using the `log-level` option in
loader.conf. Valid values are debug, info, notice, warning, err, crit,
alert, and emerg. By default, info will be used.
- Actually pass the new memory file path to parent_loaded_image->FilePath
- Restore old parent_loaded_image if Linux returns
- Pass the same kernel_file_path in load_via_boot_services path
- s/Re-use/Patch in comment explaining what we are doing
Fixes#38566
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
