verify_pe() only checked SizeOfOptionalHeader against a SIZE_MAX wrap (a
clause that, given SizeOfOptionalHeader is a uint16_t, can never reject
anything) and never read NumberOfRvaAndSizes. But pe_kernel_info(),
pe_kernel_check_nx_compat() and pe_kernel_check_no_relocation() then read
SizeOfImage, AddressOfEntryPoint, DllCharacteristics and the base
relocation data directory entry from the optional header.
Require SizeOfOptionalHeader to be large enough to contain everything down
to the base relocation data directory entry, and require the image to
declare that many data directory entries.
Follow-up for bacc2ed0d5
pe_locate_sections_internal() stores each matching section's VirtualSize
and VirtualAddress into PeSectionVector.memory_size/memory_offset with
only SIZE_MAX overflow guards, never checking them against the image's
SizeOfImage.
Wire up the image's SizeOfImage down to pe_locate_sections_internal()
and skip any section whose in-memory section does not fit within it.
Follow-up for fb974ac485
pe_kernel_info() returned AddressOfEntryPoint (and the .compat section
entry_point) straight from the PE header with no check against
SizeOfImage. Since cab9c7b5a4 the stub calls the inner kernel directly
as ImageBase + entry_point, and only EFI_SIZE_TO_PAGES(SizeOfImage) pages
are allocated for it.
Follow-up for cab9c7b5a4
UEFI firmware type hwids must be matched against the current hardware first.
This change implements that. Additionally, some extra validations on the hwids
entries have also been added.
The stub copies the embedded kernel PE into an xmalloc_pages()
allocation with AllocateAnyPages, which only guarantees EFI_PAGE_SIZE
(4 KiB) alignment.
The arm64 kernel declares SectionAlignment = SZ_64K. When _text is not
64K-aligned the kernel's EFI stub reallocates and copies the image,
which can fail with EFI_OUT_OF_RESOURCES on memory-constrained firmware
(e.g. U-Boot, bounded by CONFIG_SYS_MALLOC_LEN rather than full DRAM).
The failure is non-deterministic since AllocateAnyPages returns whatever
page the allocator finds first.
Plumb SectionAlignment through pe_kernel_info() and allocate via
xmalloc_aligned_pages(). For alignment <= EFI_PAGE_SIZE (e.g. x86_64) it
reduces to a plain AllocatePages(), so the change is free there.
SectionAlignment comes from the PE header, which the spec requires to be
a power of 2. Sanitize it in pe_kernel_info() right where it is parsed:
a non-conforming value falls back to plain page alignment (matching the
behavior of older systemd-stub versions that ignored the field) rather
than propagate something that would break xmalloc_aligned_pages()'s
over-alignment maths, with a log_warning() so the fallback stays
diagnosable.
Co-developed-by: Claude <claude@anthropic.com>
Closes: #42443
Reported-By: Agathe Porte <agathe.porte@oss.qualcomm.com>
Tested-By: Agathe Porte <agathe.porte@oss.qualcomm.com>
pe_section_table_from_file already checks with SECTION_TABLE_BYTES_MAX,
do the same in pe_section_table_from_base() just in case.
Originally reported on yeswehack.com as:
YWH-PGM9780-117
Follow-up for f4e081051d
With distributions like Ubuntu and Fedora using systemd-stub to auto load
DTB's on Windows on ARM laptops, the CHID DTB match failing is expected
when that same UKI is instead booted on an ARM SystemReady system where
no DTB is necessary.
In the ARM SystemReady case showing a big red error message is undesirable
and leads to confused users and bug-reports. Lower the message to debug
level when the status is EFI_NOT_FOUND to avoid these false positive error
messages.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2444759
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
Since shim 16, it is not possible anymore to override the security arch
protocol to avoid signature check and measurements.
Also on Dell servers, EFI_SECURITY2_ARCH_PROTOCOL is not implemented, so
unexpected measurements on PCR 4 were still happening.
This just loads and run the kernel pe. We verify that there is no relocation
needed. Also for simplification, we assume and verify that the base address is
expected to be 0.
This also
- renames efifirmware_match_by_fwid() -> efi_firmware_match_by_fwid(),
- drops unnecessary wrapper efifw_get_fwid(),
- drops unnecessary inclusion of header <endian.h>,
- sort files in meson.build.
No functional change, just refactoring and follow-ups for
83bf58f39d.
UKIs can be used to bundle uefi firmwares that can be measured and
used on a confidential computing environment. There can be more than one
firmware blob bundle, each one for a specific platform. Also firmware images
can themselves be containers like IGVM files that can in turn bundle the
actual firmware blob. This change is specifically for uefi firmwares, not
IGVM container files.
This change adds support to introduce a .efifw section in UKI that can be
used for firmware blobs/images. There can be multiple such sections and each
section can contain a single firmware image.
The matching .hwids entry for a specific platform can be used to select the
most appropriate firmware blob.
ukify tool has been also changed to support addition of a firmware image
in UKI.
Since firmware gets measured automatically, we do not need to measure it
separately as a part of the UKI.
This was added originally as it was thought that Windows applied
the same cap. Nowadays the specs do not mention it, and it is
believed Windows no longer applies it either, so drop it in order
to allow an arbitrary number of DTBs to be included
Fixes https://github.com/systemd/systemd/issues/35943
When devices of different types are present, chid_match() should only try to
match the devices that are of specific type. The caller of chid_match()
provides the type of device to match against and chid_match() should only try
to find a match against this device type.
This change also adds necessary unit test changes for the new uefi firmware
type device entry.
I very much dislike the approach in which we were mixing Linux and UEFI C code
in the same subdirectory. No code was shared between two environments. This
layout was created in e7dd673d1e, with the
justification of "being more consistent with the rest of systemd", but I don't
see how it's supposed to be so.
Originally, when the C code was just a single bootctl.c file, this wasn't so
bad. But over time the userspace code grew quite a bit. With the moves done in
previuos commits, the intermediate subdirectory is now empty except for the
efi/ subdir, and this additional subdirectory level doesn't have a good
justification. The components is called "systemd-boot", not "systemd-efi", and
we can remove one level of indentation.
Luca Boccassi
Ani Sinha
Josh Hoffer
Mike Yuan
Hans de Goede
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Valentin David
Daan De Meyer
Samuel Dionne-Riel
Lennart Poettering
anonymix007
Zbigniew Jędrzejewski-Szmek