Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.21 2025-08-09T15:10:01+00:00 2025-08-09T15:10:01+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-08-09T15:10:01+00:00 urn:sha1:402e262d77cd8b075a56809e30e6903ef648ad1a Pull EFI updates from Ard Biesheuvel: - Expose the OVMF firmware debug log via sysfs - Lower the default log level for the EFI stub to avoid corrupting any splash screens with unimportant diagnostic output * tag 'efi-next-for-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: add API doc entry for ovmf_debug_log efistub: Lower default log level efi: add ovmf debug log driver 2025-07-24T23:55:11+00:00 Kees Cook kees@kernel.org 2025-07-24T05:50:26+00:00 urn:sha1:8245d47cfaba8a38337a447230b4d01f9946f5e1 GCC appears to have kind of fragile inlining heuristics, in the sense that it can change whether or not it inlines something based on optimizations. It looks like the kcov instrumentation being added (or in this case, removed) from a function changes the optimization results, and some functions marked "inline" are _not_ inlined. In that case, we end up with __init code calling a function not marked __init, and we get the build warnings I'm trying to eliminate in the coming patch that adds __no_sanitize_coverage to __init functions: WARNING: modpost: vmlinux: section mismatch in reference: xbc_exit+0x8 (section: .text.unlikely) -> _xbc_exit (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: real_mode_size_needed+0x15 (section: .text.unlikely) -> real_mode_blob_end (section: .init.data) WARNING: modpost: vmlinux: section mismatch in reference: __set_percpu_decrypted+0x16 (section: .text.unlikely) -> early_set_memory_decrypted (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: memblock_alloc_from+0x26 (section: .text.unlikely) -> memblock_alloc_try_nid (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: acpi_arch_set_root_pointer+0xc (section: .text.unlikely) -> x86_init (section: .init.data) WARNING: modpost: vmlinux: section mismatch in reference: acpi_arch_get_root_pointer+0x8 (section: .text.unlikely) -> x86_init (section: .init.data) WARNING: modpost: vmlinux: section mismatch in reference: efi_config_table_is_usable+0x16 (section: .text.unlikely) -> xen_efi_config_table_is_usable (section: .init.text) This problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it), but we've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on. For x86 this means forcing several functions to be inline with __always_inline. Link: https://lore.kernel.org/r/20250724055029.3623499-2-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org> 2025-07-09T10:31:38+00:00 Gerd Hoffmann kraxel@redhat.com 2025-07-08T12:56:23+00:00 urn:sha1:f393a761763c542761abcf978252d431269366d6 Recent OVMF versions (edk2-stable202508 + newer) can write their debug log to a memory buffer. This driver exposes the log content via sysfs (/sys/firmware/efi/ovmf_debug_log). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 2025-02-04T13:08:22+00:00 Ard Biesheuvel ardb@kernel.org 2025-02-01T17:21:36+00:00 urn:sha1:bbc4578537e350d5bf8a7a2c7d054d6b163b3c41 For legibility, use the existing BIT_ULL() to generate the u64 type EFI memory attribute macros. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 2025-02-04T13:08:22+00:00 Ard Biesheuvel ardb@kernel.org 2025-02-01T17:21:35+00:00 urn:sha1:ba69e0750b0362870294adab09339a0c39c3beaf UEFI 2.11 introduced EFI_MEMORY_HOT_PLUGGABLE to annotate system memory regions that are 'cold plugged' at boot, i.e., hot pluggable memory that is available from early boot, and described as system RAM by the firmware. Existing loaders and EFI applications running in the boot context will happily use this memory for allocating data structures that cannot be freed or moved at runtime, and this prevents the memory from being unplugged. Going forward, the new EFI_MEMORY_HOT_PLUGGABLE attribute should be tested, and memory annotated as such should be avoided for such allocations. In the EFI stub, there are a couple of occurrences where, instead of the high-level AllocatePages() UEFI boot service, a low-level code sequence is used that traverses the EFI memory map and carves out the requested number of pages from a free region. This is needed, e.g., for allocating as low as possible, or for allocating pages at random. While AllocatePages() should presumably avoid special purpose memory and cold plugged regions, this manual approach needs to incorporate this logic itself, in order to prevent the kernel itself from ending up in a hot unpluggable region, preventing it from being unplugged. So add the EFI_MEMORY_HOTPLUGGABLE macro definition, and check for it where appropriate. Cc: stable@vger.kernel.org Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 2025-01-14T07:34:24+00:00 Ard Biesheuvel ardb@kernel.org 2024-12-19T09:27:08+00:00 urn:sha1:144d52dd8fc83a082a275e1b663e7454d2b616a4 UGA is the EFI graphical output protocol that preceded GOP, and has been long obsolete. Drop support for it from the x86 implementation of the EFI stub - other architectures never bothered to implement it (save for ia64) Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 2024-11-15T16:40:00+00:00 Nicolas Saenz Julienne nsaenz@amazon.com 2024-11-12T18:52:16+00:00 urn:sha1:7eb4e1dd71009472215bc1f8226ee9a041da8d37 Drop support for the EFI_PROPERTIES_TABLE. It was a failed, short-lived experiment that broke the boot both on Linux and Windows, and was replaced by the EFI_MEMORY_ATTRIBUTES_TABLE shortly after. Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 2024-08-27T10:22:18+00:00 Yue Haibing yuehaibing@huawei.com 2024-08-08T14:05:54+00:00 urn:sha1:21b91d40575fb64f3f280f6c3af586e32a704a92 Since commit cf8e8658100d ("arch: Remove Itanium (IA-64) architecture"), this is not used anymore. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 2024-07-12T08:06:01+00:00 Kees Cook kees@kernel.org 2024-07-11T17:11:13+00:00 urn:sha1:4a2ebb082297f41803742729642961532e54079e While efi_memory_attributes_table_t::entry isn't used directly as an array, it is used as a base for pointer arithmetic. The type is wrong as it's not technically an array of efi_memory_desc_t's; they could be larger. Regardless, leave the type unchanged and remove the old style "0" array size. Additionally replace the open-coded entry offset code with the existing efi_memdesc_ptr() helper. Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 2024-07-12T08:06:01+00:00 Kees Cook kees@kernel.org 2024-07-11T17:11:12+00:00 urn:sha1:887c4cf5594a073fd60c0df84150eb06d78c6406 The "early" part of the helper's name isn't accurate[1]. Drop it in preparation for adding a new (not early) usage. Suggested-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/lkml/CAMj1kXEyDjH0uu3Z4eBesV3PEnKGi5ArXXMp7R-hn8HdRytiPg@mail.gmail.com [1] Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>