On x86 EFI follows the windows ABI, which expects 8-byte aligned long
long. The x86 sysv ELF ABI expects them to be 8-byte aligned when used
alone, but 4-byte aligned when they appear inside of structs:
struct S {
int i;
long long ll;
};
// _Static_assert(sizeof(struct S) == 12, "x86 sysv ABI");
_Static_assert(sizeof(struct S) == 16, "EFI/MS ABI");
To get the behavior we need when building with sysv ELF ABI we need to
pass '-malign-double' to the compiler as done by EDK2.
This in turn will make ubsan unhappy as the stack may not be properly
aligned on entry, so we have to tell the compiler explicitly to re-align
the stack on entry to efi_main.
This fixes loading EFI drivers on x86 that were previously always
rejected as the EFI_LOADED_IMAGE_PROTOCOL had a wrong memory layout.
See also: https://github.com/rhboot/shim/pull/516
get_file_version() would return:
- various negative errors if the file could not be accessed or if it was not a
regular file
- 0/NULL if the file was too small
- -ESRCH or -EINVAL if the file did not contain the marker
- -ENOMEM or permissions errors
- 1 if the marker was found
bootctl status iterates over /EFI/{systemd,BOOT}/*.efi and checks if the files
contain a systemd-boot version tag. Resource or permission errors should be
fatal, but lack of version information should be silently ignored.
OTOH, when updating or installing bootloader files, the version is expected
to be present.
get_file_version() is changed to return -ESRCH if the version is unavailable,
and other errnos for permission or resource errors.
The logging is reworked to always display an error if encountered, but also
to log the status at debug level what the result of the version inquiry is.
This makes it figure out what is going on:
/efi/EFI/systemd/systemd-bootx64.efi: EFI binary LoaderInfo marker: "systemd-boot 253-6.fc38"
/efi/EFI/BOOT/BOOTfbx64.efi: EFI binary has no LoaderInfo marker.
/efi/EFI/BOOT/BOOTIA32.EFI: EFI binary has no LoaderInfo marker.
/efi/EFI/BOOT/BOOTX64.EFI: EFI binary LoaderInfo marker: "systemd-boot 253-6.fc38"
Replaces #27034.
Fixes https://github.com/NixOS/nixpkgs/issues/223579.
No functional change, just preparation for later commits.
These can be used in kernel-install later.
Note, unlike the our usual coding style, the arguments for
boot_entry_token_ensure() and parse_boot_entry_token_type() are
referenced, updated, and may freed, hence, always pass initialized
values. That's why they are not named as 'ret_xyz'.
Chasing symlinks is a core function that's used in a lot of places
so it deservers a less verbose names so let's rename it to chase()
and chaseat().
We also slightly change the pattern used for the chaseat() helpers
so we get chase_and_openat() and similar.
Suppress errors when creating/writing EFI variables during 'bootctl update' if
'--graceful' mode is active (as the documentation indicates).
Closes#26773.
Now that we always create PE images with a non-zero image base we cannot
run into this issue anymore. Any tool that still uses the old hard-coded
section offsets will end up creating bad images with sections below the
image base. objcopy will warn about this and any PE loader will simply
refuse to load such an image. Meanwhile updated tools do not use
hard-coded offsets anymore.
Fixes the following build error:
```
../src/boot/efi/vmm.c: In function ‘get_smbios_table’:
../src/boot/efi/vmm.c:217:24: error: incompatible types when returning type ‘_Bool’ but ‘const SmbiosHeader *’ was expected
217 | return false;
| ^~~~~
```
This adds back sd-boot builds by using meson compile targets directly.
We can do this now, because userspace binaries use the special
dependency that allows us to easily separate flags, so that we don't
pass anything to EFI builds that shouldn't be passed.
Additionally, we pass a bunch of flags to hopefully disable/override any
distro provided flags that should not be used for EFI binaries.
Fixes: #12275
This drops all mentions of gnu-efi and its manual build machinery. A
future commit will bring bootloader builds back. A new bootloader meson
option is now used to control whether to build sd-boot and its userspace
tooling.
Read the magic first, try reading the full DOS exe header only in case
the magic check succeeds.
This avoids throwing an header read error on small dummy files as used
by test-kernel-install.