kernel.git/drivers/firmware/efi/libstub, branch linux-6.18.y

efi/libstub: Fix page table access in 5-level to 4-level paging transition

2025-12-18T13:02:51Z

[ Upstream commit 84361123413efc84b06f3441c6c827b95d902732 ] When transitioning from 5-level to 4-level paging, the existing code incorrectly accesses page table entries by directly dereferencing CR3 and applying PAGE_MASK. This approach has several issues: - __native_read_cr3() returns the raw CR3 register value, which on x86_64 includes not just the physical address but also flags Bits above the physical address width of the system (i.e. above __PHYSICAL_MASK_SHIFT) are also not masked. - The pgd value is masked by PAGE_SIZE which doesn't take into account the higher bits such as _PAGE_BIT_NOPTISHADOW. Replace this with proper accessor functions: - native_read_cr3_pa(): Uses CR3_ADDR_MASK to additionally mask metadata out of CR3 (like SME or LAM bits). All remaining bits are real address bits or reserved and must be 0. - mask pgd value with PTE_PFN_MASK instead of PAGE_MASK, accounting for flags above bit 51 (_PAGE_BIT_NOPTISHADOW in particular). Bits below 51, but above the max physical address are reserved and must be 0. Fixes: cb1c9e02b0c1 ("x86/efistub: Perform 4/5 level paging switch from the stub") Reported-by: Michael van der Westhuizen Reported-by: Tobias Fleig Co-developed-by: Kiryl Shutsemau Signed-off-by: Kiryl Shutsemau Signed-off-by: Usama Arif Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20251103141002.2280812-3-usamaarif642@gmail.com Signed-off-by: Sasha Levin

Merge tag 'efi-next-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2025-10-05T19:08:14Z

Pull EFI updates from Ard Biesheuvel: - Document what OVMF stands for (Open Virtual Machine Firmware) - Clear NX restrictions also from 'more reliable' type memory when using the DXE service API * tag 'efi-next-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi/x86: Memory protection on EfiGcdMemoryTypeMoreReliable efi: Explain OVMF acronym in OVMF_DEBUG_LOG help text

efi/x86: Memory protection on EfiGcdMemoryTypeMoreReliable

2025-09-29T15:13:39Z

Check for needed memory protection changes on EFI DXE GCD memory space descriptors with type EfiGcdMemoryTypeMoreReliable in addition to EfiGcdMemoryTypeSystemMemory. This fixes a fault on entry into the decompressed kernel from the EFI stub that occurs when the memory allocated for the decompressed kernel is more reliable memory, has NX/XP set, and the kernel needs to use the EFI DXE protocol to adjust memory protections. The memory descriptors returned by the DXE protocol GetMemorySpaceDescriptor() service use a different GCD memory type to distinguish more reliable memory ranges from their conventional counterparts. This is in contrast to the EFI memory descriptors returned by the EFI GetMemoryMap() service which use the EFI_MEMORY_MORE_RELIABLE memory attributes flag to identify EFI_CONVENTIONAL_MEMORY type regions that have this additional property. Signed-off-by: Lenny Szubowicz Signed-off-by: Ard Biesheuvel

efistub/x86: Remap inittext read-execute when needed

2025-09-03T16:05:42Z

Recent EFI x86 systems are more strict when it comes to mapping boot images, and require that mappings are either read-write or read-execute. Now that the boot code is being cleaned up and refactored, most of it is being moved into .init.text [where it arguably belongs] but that implies that when booting on such strict EFI firmware, we need to take care to map .init.text (and the .altinstr_aux section that follows it) read-execute as well. Signed-off-by: Ard Biesheuvel Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20250828102202.1849035-44-ardb+git@google.com

Merge tag 'efi-next-for-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2025-08-09T15:10:01Z

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

Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2025-07-30T03:21:54Z

Pull arm64 updates from Catalin Marinas: "A quick summary: perf support for Branch Record Buffer Extensions (BRBE), typical PMU hardware updates, small additions to MTE for store-only tag checking and exposing non-address bits to signal handlers, HAVE_LIVEPATCH enabled on arm64, VMAP_STACK forced on. There is also a TLBI optimisation on hardware that does not require break-before-make when changing the user PTEs between contiguous and non-contiguous. More details: Perf and PMU updates: - Add support for new (v3) Hisilicon SLLC and DDRC PMUs - Add support for Arm-NI PMU integrations that share interrupts between clock domains within a given instance - Allow SPE to be configured with a lower sample period than the minimum recommendation advertised by PMSIDR_EL1.Interval - Add suppport for Arm's "Branch Record Buffer Extension" (BRBE) - Adjust the perf watchdog period according to cpu frequency changes - Minor driver fixes and cleanups Hardware features: - Support for MTE store-only checking (FEAT_MTE_STORE_ONLY) - Support for reporting the non-address bits during a synchronous MTE tag check fault (FEAT_MTE_TAGGED_FAR) - Optimise the TLBI when folding/unfolding contiguous PTEs on hardware with FEAT_BBM (break-before-make) level 2 and no TLB conflict aborts Software features: - Enable HAVE_LIVEPATCH after implementing arch_stack_walk_reliable() and using the text-poke API for late module relocations - Force VMAP_STACK always on and change arm64_efi_rt_init() to use arch_alloc_vmap_stack() in order to avoid KASAN false positives ACPI: - Improve SPCR handling and messaging on systems lacking an SPCR table Debug: - Simplify the debug exception entry path - Drop redundant DBG_MDSCR_* macros Kselftests: - Cleanups and improvements for SME, SVE and FPSIMD tests Miscellaneous: - Optimise loop to reduce redundant operations in contpte_ptep_get() - Remove ISB when resetting POR_EL0 during signal handling - Mark the kernel as tainted on SEA and SError panic - Remove redundant gcs_free() call" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (93 commits) arm64/gcs: task_gcs_el0_enable() should use passed task arm64: Kconfig: Keep selects somewhat alphabetically ordered arm64: signal: Remove ISB when resetting POR_EL0 kselftest/arm64: Handle attempts to disable SM on SME only systems kselftest/arm64: Fix SVE write data generation for SME only systems kselftest/arm64: Test SME on SME only systems in fp-ptrace kselftest/arm64: Test FPSIMD format data writes via NT_ARM_SVE in fp-ptrace kselftest/arm64: Allow sve-ptrace to run on SME only systems arm64/mm: Drop redundant addr increment in set_huge_pte_at() kselftest/arm4: Provide local defines for AT_HWCAP3 arm64: Mark kernel as tainted on SAE and SError panic arm64/gcs: Don't call gcs_free() when releasing task_struct drivers/perf: hisi: Support PMUs with no interrupt drivers/perf: hisi: Relax the event number check of v2 PMUs drivers/perf: hisi: Add support for HiSilicon SLLC v3 PMU driver drivers/perf: hisi: Use ACPI driver_data to retrieve SLLC PMU information drivers/perf: hisi: Add support for HiSilicon DDRC v3 PMU driver drivers/perf: hisi: Simplify the probe process for each DDRC version perf/arm-ni: Support sharing IRQs within an NI instance perf/arm-ni: Consolidate CPU affinity handling ...

Merge tag 'hardening-v6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2025-07-29T00:16:12Z

Pull hardening updates from Kees Cook: - Introduce and start using TRAILING_OVERLAP() helper for fixing embedded flex array instances (Gustavo A. R. Silva) - mux: Convert mux_control_ops to a flex array member in mux_chip (Thorsten Blum) - string: Group str_has_prefix() and strstarts() (Andy Shevchenko) - Remove KCOV instrumentation from __init and __head (Ritesh Harjani, Kees Cook) - Refactor and rename stackleak feature to support Clang - Add KUnit test for seq_buf API - Fix KUnit fortify test under LTO * tag 'hardening-v6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: (22 commits) sched/task_stack: Add missing const qualifier to end_of_stack() kstack_erase: Support Clang stack depth tracking kstack_erase: Add -mgeneral-regs-only to silence Clang warnings init.h: Disable sanitizer coverage for __init and __head kstack_erase: Disable kstack_erase for all of arm compressed boot code x86: Handle KCOV __init vs inline mismatches arm64: Handle KCOV __init vs inline mismatches s390: Handle KCOV __init vs inline mismatches arm: Handle KCOV __init vs inline mismatches mips: Handle KCOV __init vs inline mismatch powerpc/mm/book3s64: Move kfence and debug_pagealloc related calls to __init section configs/hardening: Enable CONFIG_INIT_ON_FREE_DEFAULT_ON configs/hardening: Enable CONFIG_KSTACK_ERASE stackleak: Split KSTACK_ERASE_CFLAGS from GCC_PLUGINS_CFLAGS stackleak: Rename stackleak_track_stack to __sanitizer_cov_stack_depth stackleak: Rename STACKLEAK to KSTACK_ERASE seq_buf: Introduce KUnit tests string: Group str_has_prefix() and strstarts() kunit/fortify: Add back "volatile" for sizeof() constants acpi: nfit: intel: avoid multiple -Wflex-array-member-not-at-end warnings ...

stackleak: Rename STACKLEAK to KSTACK_ERASE

2025-07-22T04:35:01Z

In preparation for adding Clang sanitizer coverage stack depth tracking that can support stack depth callbacks: - Add the new top-level CONFIG_KSTACK_ERASE option which will be implemented either with the stackleak GCC plugin, or with the Clang stack depth callback support. - Rename CONFIG_GCC_PLUGIN_STACKLEAK as needed to CONFIG_KSTACK_ERASE, but keep it for anything specific to the GCC plugin itself. - Rename all exposed "STACKLEAK" names and files to "KSTACK_ERASE" (named for what it does rather than what it protects against), but leave as many of the internals alone as possible to avoid even more churn. While here, also split "prev_lowest_stack" into CONFIG_KSTACK_ERASE_METRICS, since that's the only place it is referenced from. Suggested-by: Ingo Molnar Link: https://lore.kernel.org/r/20250717232519.2984886-1-kees@kernel.org Signed-off-by: Kees Cook

efistub: Lower default log level

2025-07-15T01:32:53Z

Some uefi implementations will write the efistub logs to the display over a splash image. This is not desirable for debug and info logs, so lower the default efi log level to exclude them. Suggested-by: Ard Biesheuvel Signed-off-by: Aaron Kling Signed-off-by: Ard Biesheuvel

arm64: fix unnecessary rebuilding when CONFIG_DEBUG_EFI=y

2025-07-08T13:05:29Z

When CONFIG_DEBUG_EFI is enabled, some objects are needlessly rebuilt. [Steps to reproduce] Enable CONFIG_DEBUG_EFI and run 'make' twice in a clean source tree. On the second run, arch/arm64/kernel/head.o is rebuilt even though no files have changed. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- clean $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- [ snip ] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CALL scripts/checksyscalls.sh AS arch/arm64/kernel/head.o AR arch/arm64/kernel/built-in.a AR arch/arm64/built-in.a AR built-in.a [ snip ] The issue is caused by the use of the $(realpath ...) function. At the time arch/arm64/kernel/Makefile is parsed on the first run, $(objtree)/vmlinux does not exist. As a result, $(realpath $(objtree)/vmlinux) expands to an empty string. On the second run of Make, $(objtree)/vmlinux already exists, so $(realpath $(objtree)/vmlinux) expands to the absolute path of vmlinux. However, this change in the command line causes arch/arm64/kernel/head.o to be rebuilt. To address this issue, use $(abspath ...) instead, which does not require the file to exist. While $(abspath ...) does not resolve symlinks, this should be fine from a debugging perspective. The GNU Make manual [1] clearly explains the difference between the two: $(realpath names...) For each file name in names return the canonical absolute name. A canonical name does not contain any . or .. components, nor any repeated path separators (/) or symlinks. In case of a failure the empty string is returned. Consult the realpath(3) documentation for a list of possible failure causes. $(abspath namees...) For each file name in names return an absolute name that does not contain any . or .. components, nor any repeated path separators (/). Note that, in contrast to realpath function, abspath does not resolve symlinks and does not require the file names to refer to an existing file or directory. Use the wildcard function to test for existence. The same problem exists in drivers/firmware/efi/libstub/Makefile.zboot. On the first run of Make, $(obj)/vmlinuz.efi.elf does not exist when the Makefile is parsed, so -DZBOOT_EFI_PATH is set to an empty string. Replace $(realpath ...) with $(abspath ...) there as well. [1]: https://www.gnu.org/software/make/manual/make.html#File-Name-Functions Fixes: 757b435aaabe ("efi: arm64: Add vmlinux debug link to the Image binary") Fixes: a050910972bb ("efi/libstub: implement generic EFI zboot") Signed-off-by: Masahiro Yamada Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20250625125555.2504734-1-masahiroy@kernel.org Signed-off-by: Will Deacon