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.
Let's read more kernel command line arguments from SMBIOS OEM string
io.systemd.stub.kernel-cmdline-extra. This allows adding debug kernel
command line arguments when booting in qemy without having to modify
the UKI.
Now that device path types are marked as packed we can safely cast and
access them. If we ever take the address of a member, we would get a
compiler warning.
In gnu-efi/EDK2 device paths are not marked as packed and instead the
Length field is split into 2 bytes. Accessing those requires these
helper macros as device paths may be unaligned.
Since our own efi headers define device path structs as packed, we can
access these directly, making code much more readable.
These are provided by libc instead of the compiler and are not supposed
to be used in freestanding environments.
When cross-compiling with clang and the corresponding gcc
cross-toolchain is not around, clang may pick up the wrong header from
the host system.
An rpminspect test in Fedora/RHEL is flagging our stub files as having an
executable stack. The check is correct:
$ readelf --wide --program-headers build/src/boot/efi/linuxx64.elf.stub | rg -i stack
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10
It seems to be just an omission in the linker script… None of the objects that
are linked into the stub are marked as requiring an executable stack:
$ readelf --wide --sections build/src/boot/efi/*.c.o \
/usr/lib/gnuefi/x64/libgnuefi.a \
/usr/lib/gnuefi/x64/libefi.a \
/usr/lib/gcc/x86_64-redhat-linux/12/libgcc.a \
| rg '.note.GNU-stack.*X'
(nothing)
On aarch64 we end up with a nonexecutable stack, but on ia32 and x64 we get one,
so this might be just a matter of defaults in the linker. It doesn't matter
greatly, but let's mark the stack as non-executable to avoid the warning.
Note: '-Wl,-z' is not needed, things work with just '-z'.
We already have this nice code in system that determines the block
device backing the root file system, but it's only used internally in
systemd-gpt-generator. Let's make this more accessible and expose it
directly in bootctl.
It doesn't fit immediately into the topic of bootctl, but I think it's
close enough and behaves very similar to the existing "bootctl
--print-boot-path" and "--print-esp-path" tools.
If --print-root-device (or -R) is specified once, will show the block device
backing the root fs, and if specified twice (probably easier: -RR) it
will show the whole block device that block device belongs to in case it
is a partition block device.
Suggested use:
# cfdisk `bootctl -RR`
To get access to the partition table, behind the OS install, for
whatever it might be.
Although this slightly more verbose it makes it much easier to reason
about. The code that produces the tests heavily benefits from this.
Test lists are also now sorted by test name.
We want to get away from gnu-efi and the only really usable source of
EFI headers would be EDK2, which is somewhat impractical to use and
quite large to require to be around just for some headers.
As a bonus point, the new headers are safe to be included in userspace
code.
This should not have any behavior changes as it is mostly changing
header includes. There are some renames to conform to standard names
and a few minor device path fixups as the struct is defined slightly
different.
Of note is that this removes usage of uchar.h and wchar.h as they are
not guaranteed to be available in a freestanding environment. Instead
efi.h will provide the needed types.
Jan Janssen
Daan De Meyer
Yu Watanabe
Morten Linderud
Dan Streetman
Gerd Hoffmann
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
David Tardon