The stub image may not have enough sections to cause enough PE header
space to be free for later expansion. Given that the stub is guaranteed
to be expanded we should always reserve enough sections for it.
This also bumps the reservation to 15. It doesn't add more space
compared to current builds but it more closely reflects the amount of
sections that a UKI could have in total if all optional sections are
used.
Fixes: #28593
When building on a x32 system we need to explicitly pass `-m64` to get
the right ABI as the kernel and EFI are still 64bit. For this to
actually work, a suitable multilib compiler, 32bit libc headers and
libgcc need to be installed (similar to ia32 builds on x86_64).
Without this, the tests would generally be skipped, since we haven't made a
release with the addon stub yet. But even if the file is there, we always want
to test the freshly-built item.
Files placed in /EFI/Linux/UKI.efi.extra.d/ and /loader/addons/ are
opened and verified using the LoadImage protocol, and will thus get
verified via shim/firmware.
If they are valid signed PE files, the .cmdline section will be
extracted and appended. If there are multiple addons in each directory,
they will be parsed in alphanumerical order.
Optionally the .uname sections are also matched if present, so
that they can be used to filter out addons as well if needed, and only
addons that correspond exactly to the UKI being loaded are used.
It is recommended to also always add a .sbat section to addons, so
that they can be mass-revoked with just a policy update.
The files must have a .addon.efi suffix.
Files in the per-UKI directory are parsed, sorted, measured and
appended first. Then, files in the generic directory are processed.
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
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.
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'.
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.
Binutils 2.38 added support for efi-app-aarch64
Still use binary mode if we have an older objcopy
Add check for incompatible gnu-efi crt0 containing the header section
which gets added by objcopy and if used results in duplicate header
and subsequently a broken binary
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
libefi.a just provided the c helper API that was slowly removed. As we
do not depend on anything provided by it anymore, it is safe to drop
now.
Since the ST/BS/RT pointers are very convenient and needed everywhere,
they are retained and initialized by us.
Removing debugging related sections is apparently not enough to truely
strip a (PE) binary.
Better late than never. It gets rid of this pesky warning from sbsign:
warning: data remaining[174080 vs 193173]: gaps between PE/COFF sections?
Now that we have ukify and mkosi has been updated to use it, we
have a solution in place to make sure that PE sections don't overlap
in a UKI so let's drop the workaround to avoid overlapping PE sections.
We converted to not using #ifdef for most of our defines because the syntax is
nicer and we are protected against typos and can set -Werror=undef. Let's do
the same for SD_BOOT. The define is nicely hidden in build.h for normal builds,
and for EFI builds we were already setting SD_BOOT on the commandline.
sd-stub has an opportunity to handle the seed the same way sd-boot does,
which would have benefits for UKIs when sd-boot is not in use. This
commit wires that up.
It refactors the XBOOTLDR partition discovery to also find the ESP
partition, so that it access the random seed there.
systemd-boot expects being loaded from ESP and is quite unhappy in case
the loaded image device path is something else. When running on qemu
this can easily happen though. Case one is direct kernel boot, i.e.
loading via 'qemu -kernel systemd-bootx64.efi'. Case two is sd-boot
being added to the ovmf firmware image and being loaded from there.
This patch detects both cases and goes inspect all file systems known to
the firmware, trying to find the ESP. When present the
VMMBootOrderNNNN variables are used to inspect the file systems in the
given order.
The kernel PE image version can be used to detect support for this
feature, allowing us to prefer the generic code of the deprecated EFI
handover protocol.
The warning isn't that serious and mostly there to inform the user that
lld/mold cannot build efi binaries. It is also better to build test with
fatal meson warnings.
Luca Boccassi
Jan Janssen
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Callum Farmer
Daan De Meyer
Jason A. Donenfeld
Gerd Hoffmann
Lennart Poettering