boot_entry_parse_tries() replaces the id, which means the id
with the profile appended is lost (leaked) and replaced by a plain filename
in case there are tries suffixes. This means the wrong order is used in
displaying the entries in the menu, as the main profile is always last
given id_without_profile has the tries suffixes and sorts higher,
while the main profile has no id_without_profile and the id sorts lower
since it does not have the tries suffix.
Follow-up for 4301ad00ef
Otherwise, musl defines wchar_t as int, which conflicts with the
assumption by sd-boot, i.e. wchar_t is 2 bytes.
Fixes the following build error:
```
In file included from ../src/boot/efi-log.h:4,
from ../src/boot/linux_x86.c:13:
../src/boot/efi.h:19:24: error: conflicting types for 'wchar_t'; have 'short unsigned int'
19 | typedef __WCHAR_TYPE__ wchar_t;
| ^~~~~~~
In file included from /usr/include/stddef.h:19,
from ../src/boot/efi.h:9:
/usr/include/bits/alltypes.h:10:13: note: previous declaration of 'wchar_t' with type 'wchar_t' {aka 'int'}
10 | typedef int wchar_t;
| ^~~~~~~
```
shim is often used as part of the EFI boot chain with Linux kernels.
shim has an option to disable all verification of binaries it loads.
This can be performed by end-user using mokutil / mokmanager EFI app,
which set BootServices only variable MokSBState. shim honors that, and
mirrors it as readonly MokSBStateRT for the post-ExitBootService access.
Thus presense of MokSBStateRT is an indicator that shim was used during
boot chain.
Some OEM vendors are known to set MokSBState variable, without user
having done so.
When verification is disabled, one should assume secureboot is insecure,
because any EFI binary was allowed to run, including but not limited to
unsigned or revoked:
- grub
- systemd-boot
- UKI
- linux kernel
Linux kernel also has code to check this variable, and correctly report
that Secure Boot is disabled, see:
-
3a86608788/drivers/firmware/efi/libstub/secureboot.c (L57)
With this change bootctl output changes like this:
```diff
System:
Firmware: n/a (n/a)
Firmware Arch: x64
- Secure Boot: enabled (user)
+ Secure Boot: disabled (insecure)
TPM2 Support: yes
Measured UKI: no
Boot into FW: supported
```
This implementation is trying to mimic mokutil behaviour like this one:
```
$ mokutil --sb-state
SecureBoot enabled
SecureBoot validation is disabled in shim
```
As well as the linux kernel behavior of:
```
$ journalctl -b | grep 'Secure boot disabled'
kernel: Secure boot disabled
```
Note that MokSBState is extended into PCR7 as well as also into PCR14.
For more details see https://github.com/rhboot/shim/blob/main/README.tpm
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.
