aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/firmware/efi/libstub
AgeCommit message (Collapse)AuthorFilesLines
2026-06-21Merge tag 'mm-nonmm-stable-2026-06-21-10-22' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds1-2/+4
Pull non-MM updates from Andrew Morton: - "taskstats: fix TGID dead-thread stat retention" (Yiyang Chen) Fix a taskstats TGID aggregation bug where fields added in the TGID query path were not preserved after thread exit, and adds a kselftest covering the regression. - "lib/tests: string_helpers: Slight improvements" (Andy Shevchenko) Improve lib/tests/string_helpers_kunit.c a little - "lib/base64: decode fixes" (Josh Law) Address minor issues in lib/base64.c - "selftests/filelock: Make output more kselftestish" (Mark Brown) Make the output from the ofdlocks test a bit easier for tooling to work with. Also ignore the generated file - "uaccess: unify inline vs outline copy_{from,to}_user() selection" (Yury Norov) Simplify the usercopy code by removing the selectability of inlining copy_{from,to}_user(). - "ocfs2: validate inline xattr header consumers" (ZhengYuan Huang) Fix a number of possible issues in the ocfs2 xattr code - "lib and lib/cmdline enhancements" (Dmitry Antipov) Provide additional robustness checking in the cmdline handling code and its in-kernel testing and selftests - "cleanup the RAID6 P/Q library" (Christoph Hellwig) Clean up the RAID6 P/Q library to match the recent updates to the RAID 5 XOR library and other CRC/crypto libraries - "ocfs2: harden inode validators against forged metadata" (Michael Bommarito) Add three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode - "lib/raid: replace __get_free_pages() call with kmalloc()" (Mike Rapoport) Clean up the lib/raid code by using kmalloc() in more places * tag 'mm-nonmm-stable-2026-06-21-10-22' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (108 commits) ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits lib: interval_tree_test: validate benchmark parameters ocfs2: avoid moving extents to occupied clusters treewide: fix transposed "sign" typos and update spelling.txt ocfs2: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec fat: reject BPB volumes whose data area starts beyond total sectors selftests/uevent: increase __UEVENT_BUFFER_SIZE to avoid ENOBUFS on busy systems lib/test_firmware: allocate the configured into_buf size fs: efs: remove unneeded debug prints checkpatch: cuppress warnings when Reported-by: is followed by Link: MAINTAINERS: add Alexander as a kcov reviewer mailmap: update Alexander Sverdlin's Email addresses fs: fat: inode: replace sprintf() with scnprintf() ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent ocfs2: fix race between ocfs2_control_install_private() and ocfs2_control_release() ocfs2/dlm: require a ref for locking_state debugfs open ocfs2: reject FITRIM ranges shorter than a cluster ocfs2: validate fast symlink target during inode read ocfs2: add journal NULL check in ocfs2_checkpoint_inode() ...
2026-06-15Merge tag 'x86-cpu-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-0/+1
Pull x86 cpuid updates from Ingo Molnar: - CPUID API updates (Ahmed S. Darwish): - Introduce a centralized CPUID parser - Introduce a centralized CPUID data model - Introduce <asm/cpuid/leaf_types.h> - Rename cpuid_leaf()/cpuid_subleaf() APIs - treewide: Explicitly include the x86 CPUID headers - Update to x86-cpuid-db v3.1 (Maciej Wieczor-Retman) - Continued removal of pre-i586 support and related simplifications (Ingo Molnar) - Add Intel CPU model number for rugged Panther Lake (Tony Luck) - Misc fixes, updates and cleanups by Arnd Bergmann, Chao Gao, Lukas Bulwahn, Sohil Mehta, Maciej Wieczor-Retman. * tag 'x86-cpu-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip: (25 commits) x86/cpu: Make CONFIG_X86_CX8 unconditional x86/cpu: Remove unused !CONFIG_X86_TSC code x86/cpuid: Update bitfields to x86-cpuid-db v3.1 tools/x86/kcpuid: Update bitfields to x86-cpuid-db v3.1 x86/cpu: Make CONFIG_X86_TSC unconditional MAINTAINERS: Drop obsolete FPU EMULATOR section x86/cpu: Fix a F00F bug warning and clean up surrounding code x86/cpu: Add Intel CPU model number for rugged Panther Lake x86/cpuid: Introduce a centralized CPUID parser x86/cpu: Introduce a centralized CPUID data model x86/cpuid: Introduce <asm/cpuid/leaf_types.h> x86/cpuid: Rename cpuid_leaf()/cpuid_subleaf() APIs x86/cpu: Do not include the CPUID API header in asm/processor.h Documentation: core-api/cpu_hotplug: Remove stale cpu0_hotplug docs x86/cpu, cpufreq: Remove AMD ELAN support x86/fpu: Remove the math-emu/ FPU emulation library x86/fpu: Remove the 'no387' boot option x86/fpu: Remove MATH_EMULATION and related glue code treewide: Explicitly include the x86 CPUID headers x86/cpu: Remove the CONFIG_X86_INVD_BUG quirk ...
2026-05-28riscv: fix building compressed EFI imageDmitry Antipov1-2/+4
When building vmlinuz.efi with CONFIG_EFI_ZBOOT enabled, '__lshrdi3()' is also needed to fix yet another link error observed when building riscv32 and loongarch32 images: riscv32-linux-gnu-ld: drivers/firmware/efi/libstub/lib-cmdline.stub.o: in function `__efistub_.L49': __efistub_cmdline.c:(.init.text+0x202): undefined reference to `__efistub___lshrdi3' /usr/bin/loongarch32-linux-gnu-ld: ./drivers/firmware/efi/libstub/lib-cmdline.stub.o: in function `__efistub_.L47': __efistub_cmdline.c:(.init.text+0x26c): undefined reference to `__efistub___lshrdi3' And since both riscv64 and loongarch64 can have CONFIG_EFI_ZBOOT but doesn't need these library routines, rely on CONFIG_32BIT to manage linking of lib-ashldi3.o and lib-lshrdi3.o on 32-bit variants only. [dmantipov@yandex.ru: fix loongarch32] Link: https://lore.kernel.org/8095016e47aceab4830c2523ce78af968ec0497e.camel@yandex.ru Link: https://lore.kernel.org/20260519172259.908980-9-dmantipov@yandex.ru Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Reported-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Closes: https://lore.kernel.org/linux-riscv/20260409050018.GA371560@inky.localdomain Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Suggested-by: Ard Biesheuvel <ardb@kernel.org> Assisted-by: Gemini:gemini-3.1-pro-preview sashiko Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Andriy Shevchenko <andriy.shevchenko@intel.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-21efi/loongarch: Randomize kernel preferred address for KASLRWANG Rui2-0/+20
Introduce efi_get_kimg_kaslr_address() helper to compute the preferred kernel image load address dynamically when CONFIG_RANDOMIZE_BASE is enabled. The function derives a random offset by using the EFI-provided randomness combined with the timer tick value, and constrains it within CONFIG_RANDOMIZE_BASE_MAX_OFFSET. Update EFI_KIMG_PREFERRED_ADDRESS to call this helper so that the EFI stub can select a randomized load address when KASLR is active, while preserving the original base address behavior when KASLR is disabled or "nokaslr" is specified. Note: LoongArch can't KASLR for hibernation, so set efi_nokaslr to true if "resume=<devname>" is explicitly specified in cmdline. Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-05-06treewide: Explicitly include the x86 CPUID headersAhmed S. Darwish1-0/+1
Modify all CPUID call sites which implicitly include any of the CPUID headers to explicitly include them instead. For KVM's reverse_cpuid.h, just include <asm/cpuid/types.h> since it references the CPUID_EAX..EDX symbols without using the CPUID APIs. Note, this allows removing the inclusion of <asm/cpuid/api.h> from within <asm/processor.h> next. That allows the CPUID API headers to include <asm/processor.h> without introducing a circular dependency. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20260327021645.555257-1-darwi@linutronix.de
2026-04-29efi/libstub: Synchronize instruction cache after kernel relocationWANG Rui1-0/+1
The relocated kernel image is copied to its new location using memcpy(). On architectures with separate instruction and data caches, the copied instructions may remain stale in the instruction cache, leading to the execution of outdated contents. Call efi_cache_sync_image() after the relocation copy to ensure the instruction cache is synchronized with the updated memory contents before control is transferred to the relocated kernel. Signed-off-by: WANG Rui <r@hev.cc> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-04-29efi/loongarch: Implement efi_cache_sync_image()WANG Rui1-0/+5
Provide a LoongArch implementation of efi_cache_sync_image() to ensure instruction cache coherency after the kernel image is relocated. Signed-off-by: WANG Rui <r@hev.cc> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-04-29efi/libstub: Move efi_relocate_kernel() into its only remaining userArd Biesheuvel5-174/+162
LoongArch is the only arch that still uses efi_relocate_kernel(), so before making changes to it that LoongArch needs, turn it into a private function. Move efi_low_alloc_above() into mem.c while at it, and drop the relocate.c source file altogether. Tested-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-04-24Merge tag 'loongarch-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongsonLinus Torvalds1-0/+1
Pull LoongArch updates from Huacai Chen: - Adjust build infrastructure for 32BIT/64BIT - Add HIGHMEM (PKMAP and FIX_KMAP) support - Show and handle CPU vulnerabilites correctly - Batch the icache maintenance for jump_label - Add more atomic instructions support for BPF JIT - Add more features (e.g. fsession) support for BPF trampoline - Some bug fixes and other small changes * tag 'loongarch-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: (21 commits) selftests/bpf: Enable CAN_USE_LOAD_ACQ_STORE_REL for LoongArch LoongArch: BPF: Add fsession support for trampolines LoongArch: BPF: Introduce emit_store_stack_imm64() helper LoongArch: BPF: Support up to 12 function arguments for trampoline LoongArch: BPF: Support small struct arguments for trampoline LoongArch: BPF: Open code and remove invoke_bpf_mod_ret() LoongArch: BPF: Support load-acquire and store-release instructions LoongArch: BPF: Support 8 and 16 bit read-modify-write instructions LoongArch: BPF: Add the default case in emit_atomic() and rename it LoongArch: Define instruction formats for AM{SWAP/ADD}.{B/H} and DBAR LoongArch: Batch the icache maintenance for jump_label LoongArch: Add flush_icache_all()/local_flush_icache_all() LoongArch: Add spectre boundry for syscall dispatch table LoongArch: Show CPU vulnerabilites correctly LoongArch: Make arch_irq_work_has_interrupt() true only if IPI HW exist LoongArch: Use get_random_canary() for stack canary init LoongArch: Improve the logging of disabling KASLR LoongArch: Align FPU register state to 32 bytes LoongArch: Handle CONFIG_32BIT in syscall_get_arch() LoongArch: Add HIGHMEM (PKMAP and FIX_KMAP) support ...
2026-04-22LoongArch: Adjust build infrastructure for 32BIT/64BITHuacai Chen1-0/+1
Adjust build infrastructure (Kconfig, Makefile and ld scripts) to let us enable both 32BIT/64BIT kernel build. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-04-16Merge tag 'efi-next-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds1-6/+6
Pull EFI updates from Ard Biesheuvel: "Again not a busy cycle for EFI, just some minor tweaks and bug fixes: - Enable boot graphics resource table (BGRT) on Xen/x86 - Correct a misguided assumption in the memory attributes table sanity check - Start tagging efi_mem_reserve()'d regions as MEMBLOCK_RSRV_KERN - Some other minor fixes and cleanups" * tag 'efi-next-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi/capsule-loader: fix incorrect sizeof in phys array reallocation efi: Tag memblock reservations of boot services regions as RSRV_KERN memblock: Permit existing reserved regions to be marked RSRV_KERN efi/memattr: Fix thinko in table size sanity check efi: libstub: fix type of fdt 32 and 64bit variables efi: Drop unused efi_range_is_wc() function efi: Enable BGRT loading under Xen efi: make efi_mem_type() and efi_mem_attributes() work on Xen PV
2026-03-12kbuild: Consolidate C dialect optionsNathan Chancellor1-2/+1
Introduce CC_FLAGS_DIALECT to make it easier to update the various places in the tree that rely on the GNU C standard and Microsoft extensions flags atomically. All remaining uses of '-std=gnu11' and '-fms-extensions' are in the tools directory (which has its own build system) and other standalone Makefiles. This will allow the kernel to use a narrower option to enable the Microsoft anonymous tagged structure extension in a simpler manner. Place the CC_FLAGS_DIALECT block after the configuration include (so that a future change can move the selection of the flag to Kconfig) but before the arch/$(SRCARCH)/Makefile include (so that CC_FLAGS_DIALECT is available for use in those Makefiles). Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Link: https://patch.msgid.link/20260223-fms-anonymous-structs-v1-1-8ee406d3c36c@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-03-11efi: libstub: fix type of fdt 32 and 64bit variablesBen Dooks1-6/+6
In update_fdt_memmap() an update_fdt() the fdt values should be of the fd32_t and fdt64_t types. Make the relevant changes to remove the following sparse warnings: drivers/firmware/efi/libstub/fdt.c:97:19: warning: incorrect type in assignment (different base types) drivers/firmware/efi/libstub/fdt.c:97:19: expected unsigned long long [usertype] fdt_val64 drivers/firmware/efi/libstub/fdt.c:97:19: got restricted __be64 [usertype] drivers/firmware/efi/libstub/fdt.c:157:19: warning: incorrect type in assignment (different base types) drivers/firmware/efi/libstub/fdt.c:157:19: expected unsigned long long [usertype] fdt_val64 drivers/firmware/efi/libstub/fdt.c:157:19: got restricted __be64 [usertype] drivers/firmware/efi/libstub/fdt.c:163:19: warning: incorrect type in assignment (different base types) drivers/firmware/efi/libstub/fdt.c:163:19: expected unsigned int [usertype] fdt_val32 drivers/firmware/efi/libstub/fdt.c:163:19: got restricted __be32 [usertype] drivers/firmware/efi/libstub/fdt.c:169:19: warning: incorrect type in assignment (different base types) drivers/firmware/efi/libstub/fdt.c:169:19: expected unsigned int [addressable] [usertype] fdt_val32 drivers/firmware/efi/libstub/fdt.c:169:19: got restricted __be32 [usertype] drivers/firmware/efi/libstub/fdt.c:175:19: warning: incorrect type in assignment (different base types) drivers/firmware/efi/libstub/fdt.c:175:19: expected unsigned int [addressable] [usertype] fdt_val32 drivers/firmware/efi/libstub/fdt.c:175:19: got restricted __be32 [usertype] Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-02-09Merge tag 'efi-next-for-v7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds7-80/+100
Pull EFI updates from Ard Biesheuvel: - Quirk the broken EFI framebuffer geometry on the Valve Steam Deck - Capture the EDID information of the primary display also on non-x86 EFI systems when booting via the EFI stub. * tag 'efi-next-for-v7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: Support EDID information sysfb: Move edid_info into sysfb_primary_display sysfb: Pass sysfb_primary_display to devices sysfb: Replace screen_info with sysfb_primary_display sysfb: Add struct sysfb_display_info efi: sysfb_efi: Reduce number of references to global screen_info efi: earlycon: Reduce number of references to global screen_info efi: sysfb_efi: Fix efidrmfb and simpledrmfb on Valve Steam Deck efi: sysfb_efi: Convert swap width and height quirk to a callback efi: sysfb_efi: Fix lfb_linelength calculation when applying quirks efi: sysfb_efi: Replace open coded swap with the macro
2025-12-24efi/libstub: gop: Fix EDID support in mixed-modeHans de Goede1-4/+4
The efi_edid_discovered_protocol and efi_edid_active_protocol have mixed mode fields. So all their attributes should be accessed through the efi_table_attr() helper. Doing so fixes the upper 32 bits of the 64 bit gop_edid pointer getting set to random values (followed by a crash at boot) when booting a x86_64 kernel on a machine with 32 bit UEFI like the Asus T100TA. Fixes: 17029cdd8f9d ("efi/libstub: gop: Add support for reading EDID") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-12-16efi: Support EDID informationThomas Zimmermann7-81/+93
In the EFI config table, rename LINUX_EFI_SCREEN_INFO_TABLE_GUID to LINUX_EFI_PRIMARY_DISPLAY_TABLE_GUID. Read sysfb_primary_display from the entry. In addition to the screen_info, the entry now also contains EDID information. In libstub, replace struct screen_info with struct sysfb_display_info from the kernel's sysfb_primary_display and rename functions accordingly. Transfer it to the runtime kernel using the kernel's global state or the LINUX_EFI_PRIMARY_DISPLAY_TABLE_GUID config-table entry. With CONFIG_FIRMWARE_EDID=y, libstub now transfers the GOP device's EDID information to the kernel. If CONFIG_FIRMWARE_EDID=n, EDID information is disabled. Make the Kconfig symbol CONFIG_FIRMWARE_EDID available with EFI. Setting the value to 'n' disables EDID support. Also rename screen_info.c to primary_display.c and adapt the contained comment according to the changes. Link: https://lore.kernel.org/all/20251126160854.553077-8-tzimmermann@suse.de/ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> [ardb: depend on EFI_GENERIC_STUB not EFI, fix conflicts after dropping the preceding patch from the series] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-12-16sysfb: Replace screen_info with sysfb_primary_displayThomas Zimmermann1-5/+13
Replace the global screen_info with sysfb_primary_display of type struct sysfb_display_info. Adapt all users of screen_info. Instances of screen_info are defined for x86, loongarch and EFI, with only one instance compiled into a specific build. Replace all of them with sysfb_primary_display. All existing users of screen_info are updated by pointing them to sysfb_primary_display.screen instead. This introduces some churn to the code, but has no impact on functionality. Boot parameters and EFI config tables are unchanged. They transfer screen_info as before. The logic in EFI's alloc_screen_info() changes slightly, as it now returns the screen field of sysfb_primary_display. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # drivers/pci/ Reviewed-by: Richard Lyu <richard.lyu@suse.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-12-13Merge tag 'loongarch-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongsonLinus Torvalds1-4/+4
Pull LoongArch updates from Huacai Chen: - Add basic LoongArch32 support Note: Build infrastructures of LoongArch32 are not enabled yet, because we need to adjust irqchip drivers and wait for GNU toolchain be upstream first. - Select HAVE_ARCH_BITREVERSE in Kconfig - Fix build and boot for CONFIG_RANDSTRUCT - Correct the calculation logic of thread_count - Some bug fixes and other small changes * tag 'loongarch-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: (22 commits) LoongArch: Adjust default config files for 32BIT/64BIT LoongArch: Adjust VDSO/VSYSCALL for 32BIT/64BIT LoongArch: Adjust misc routines for 32BIT/64BIT LoongArch: Adjust user accessors for 32BIT/64BIT LoongArch: Adjust system call for 32BIT/64BIT LoongArch: Adjust module loader for 32BIT/64BIT LoongArch: Adjust time routines for 32BIT/64BIT LoongArch: Adjust process management for 32BIT/64BIT LoongArch: Adjust memory management for 32BIT/64BIT LoongArch: Adjust boot & setup for 32BIT/64BIT LoongArch: Adjust common macro definitions for 32BIT/64BIT LoongArch: Add adaptive CSR accessors for 32BIT/64BIT LoongArch: Add atomic operations for 32BIT/64BIT LoongArch: Add new PCI ID for pci_fixup_vgadev() LoongArch: Add and use some macros for AVEC LoongArch: Correct the calculation logic of thread_count LoongArch: Use unsigned long for _end and _text LoongArch: Use __pmd()/__pte() for swap entry conversions LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT LoongArch: Fix build errors for CONFIG_RANDSTRUCT ...
2025-12-06LoongArch: Add adaptive CSR accessors for 32BIT/64BITHuacai Chen1-4/+4
32BIT platforms only have 32bit CSR/IOCSR registers, 64BIT platforms have both 32bit/64bit CSR/IOCSR registers. Now there are both 32bit and 64bit CSR accessors: csr_read32()/csr_write32()/csr_xchg32(); csr_read64()/csr_write64()/csr_xchg64(); Some CSR registers (address and timer registers) are 32bit length on 32BIT platform and 64bit length on 64BIT platform. To avoid #ifdefs here and there, they need adaptive accessors, so we define and use: csr_read()/csr_write()/csr_xchg(); IOCSR doesn't have a "natural length", which means a 64bit register can be treated as two 32bit registers, so we just use two 32bit accessors to emulate a 64bit accessors. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-12-04Merge tag 'efi-next-for-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds4-55/+215
Pull EFI updates from Ard Biesheuvel: "The usual trickle of EFI contributions: - Parse SMBIOS tables in memory directly on Macbooks that do not implement the EFI SMBIOS protocol - Obtain EDID information from the primary display while running in the EFI stub, and expose it via bootparams on x86 (generic method is in the works, and will likely land during the next cycle) - Bring CPER handling for ARM systems up to data with the latest EFI spec changes - Various cosmetic changes" * tag 'efi-next-for-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: docs: efi: add CPER functions to driver-api efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs efi/cper: Add a new helper function to print bitmasks efi/cper: Adjust infopfx size to accept an extra space RAS: Report all ARM processor CPER information to userspace efi/libstub: x86: Store EDID in boot_params efi/libstub: gop: Add support for reading EDID efi/libstub: gop: Initialize screen_info in helper function efi/libstub: gop: Find GOP handle instead of GOP data efi: Fix trailing whitespace in header file efi/memattr: Convert efi_memattr_init() return type to void efi: stmm: fix kernel-doc "bad line" warnings efi/riscv: Remove the useless failure return message print efistub/x86: Add fallback for SMBIOS record lookup
2025-12-02Merge tag 'x86_mm_for_v6.19_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-2/+2
Pull x86 mm updates from Borislav Petkov: - Use the proper accessors when reading CR3 as part of the page level transitions (5-level to 4-level, the use case being kexec) so that only the physical address in CR3 is picked up and not flags which are above the physical mask shift - Clean up and unify __phys_addr_symbol() definitions * tag 'x86_mm_for_v6.19_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/libstub: Fix page table access in 5-level to 4-level paging transition x86/boot: Fix page table access in 5-level to 4-level paging transition x86/mm: Unify __phys_addr_symbol()
2025-11-18efi/libstub: x86: Store EDID in boot_paramsThomas Zimmermann1-1/+2
Retrieve the GOP device's EDID information in the kernel's boot parameters. Makes the data avaialble to kernel graphics code and drives, such as efidrm. With efidrm, the EDID is now also available to user-space compositors via standard DRM interfaces. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-18efi/libstub: gop: Add support for reading EDIDThomas Zimmermann4-4/+67
Add support for EFI_EDID_DISCOVERED_PROTOCOL and EFI_EDID_ACTIVE_PROTOCOL as defined in UEFI 2.8, sec 12.9. Define GUIDs and data structures in the rsp header files. In the GOP setup function, read the EDID of the primary GOP device. First try EFI_EDID_ACTIVE_PROTOCOL, which supports user-specified EDID data. Or else try EFI_EDID_DISCOVERED_PROTOCOL, which returns the display device's native EDID. If no EDID could be retrieved, clear the storage. Rename efi_setup_gop() to efi_setup_graphics() to reflect the changes Let callers pass an optional instance of struct edid_data, if they are interested. While screen_info and edid_info come from the same device handle, they should be considered indendent data. The former refers to the graphics mode, the latter refers to the display device. GOP devices might not provide both. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-18efi/libstub: gop: Initialize screen_info in helper functionThomas Zimmermann1-43/+33
Move initialization of screen_info into a single helper function. Frees up space in the main setup helper for adding EDID support. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-18efi/libstub: gop: Find GOP handle instead of GOP dataThomas Zimmermann1-10/+17
The device handle of the GOP device is required to retrieve the correct EDID data. Find the handle instead of the GOP data. Still return the GOP data in the function arguments, as we already looked it up. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-06efistub/x86: Add fallback for SMBIOS record lookupFrancesco Pompo1-1/+100
Some Apple EFI firmwares do not provide the SMBIOS Protocol, causing efi_get_smbios_record() to fail. This prevents retrieval of system information such as product name, which is needed by apple_set_os() to enable the integrated GPU on dual-graphics Intel MacBooks. Add a fallback that directly parses the SMBIOS entry point table when the protocol is unavailable. Signed-off-by: Francesco Pompo <francescopompo2@gmail.com> [ardb: cosmetic tweaks] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-05efi/libstub: Fix page table access in 5-level to 4-level paging transitionUsama Arif1-2/+2
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 <rmikey@meta.com> Reported-by: Tobias Fleig <tfleig@meta.com> Co-developed-by: Kiryl Shutsemau <kas@kernel.org> Signed-off-by: Kiryl Shutsemau <kas@kernel.org> Signed-off-by: Usama Arif <usamaarif642@gmail.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20251103141002.2280812-3-usamaarif642@gmail.com
2025-10-30kbuild: Add '-fms-extensions' to areas with dedicated CFLAGSNathan Chancellor1-2/+2
This is a follow up to commit c4781dc3d1cf ("Kbuild: enable -fms-extensions") but in a separate change due to being substantially different from the initial submission. There are many places within the kernel that use their own CFLAGS instead of the main KBUILD_CFLAGS, meaning code written with the main kernel's use of '-fms-extensions' in mind that may be tangentially included in these areas will result in "error: declaration does not declare anything" messages from the compiler. Add '-fms-extensions' to all these areas to ensure consistency, along with -Wno-microsoft-anon-tag to silence clang's warning about use of the extension that the kernel cares about using. parisc does not build with clang so it does not need this warning flag. LoongArch does not need it either because -W flags from KBUILD_FLAGS are pulled into cflags-vdso. Reported-by: Christian Brauner <brauner@kernel.org> Closes: https://lore.kernel.org/20251030-meerjungfrau-getrocknet-7b46eacc215d@brauner/ Reviewed-by: Christian Brauner <brauner@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2025-10-05Merge tag 'efi-next-for-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds1-4/+6
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
2025-09-29efi/x86: Memory protection on EfiGcdMemoryTypeMoreReliableLenny Szubowicz1-4/+6
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 <lszubowi@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-09-03efistub/x86: Remap inittext read-execute when neededArd Biesheuvel1-1/+3
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 <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-44-ardb+git@google.com
2025-08-09Merge tag 'efi-next-for-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds1-2/+2
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-29Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds1-1/+1
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 ...
2025-07-28Merge tag 'hardening-v6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linuxLinus Torvalds1-4/+4
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 ...
2025-07-21stackleak: Rename STACKLEAK to KSTACK_ERASEKees Cook1-4/+4
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 <mingo@kernel.org> Link: https://lore.kernel.org/r/20250717232519.2984886-1-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-15efistub: Lower default log levelAaron Kling1-2/+2
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 <ardb@kernel.org> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-07-08arm64: fix unnecessary rebuilding when CONFIG_DEBUG_EFI=yMasahiro Yamada1-1/+1
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 <masahiroy@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250625125555.2504734-1-masahiroy@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-06-20efi: Fix .data section size calculations when .sbat is presentVitaly Kuznetsov1-2/+2
Commit 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT section") neglected to adjust the sizes of the .data section when CONFIG_EFI_SBAT_FILE is set. As the result, the produced PE binary is incorrect and some tools complain about it. E.g. 'sbsign' reports: # sbsign --key my.key --cert my.crt arch/arm64/boot/vmlinuz.efi warning: file-aligned section .data extends beyond end of file warning: checksum areas are greater than image size. Invalid section table? Note, '__data_size' is also used in the PE optional header and it is not entirely clear whether .sbat needs to be accounted as part of SizeOfInitializedData or not. As the header seems to be unused by the real world firmware, keeping the field equal to __data_size. Fixes: 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT section") Reported-by: Heinrich Schuchardt <heinrich.schuchardt@gmx.de> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-06-10efi: Drop preprocessor directives from zboot.ldsVitaly Kuznetsov1-2/+0
Older versions of `ld` don't seem to support preprocessor directives in linker scripts, e.g. on RHEL9's ld-2.35.2-63.el9 the build fails with: ld:./drivers/firmware/efi/libstub/zboot.lds:32: ignoring invalid character `#' in expression ld:./drivers/firmware/efi/libstub/zboot.lds:33: syntax error We don't seem to need these '#ifdef', no empty .sbat section is created when CONFIG_EFI_SBAT_FILE="": # objdump -h arch/arm64/boot/vmlinuz.efi arch/arm64/boot/vmlinuz.efi: file format pei-aarch64-little Sections: Idx Name Size VMA LMA File off Algn 0 .text 00b94000 0000000000001000 0000000000001000 00001000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000200 0000000000b95000 0000000000b95000 00b95000 2**2 CONTENTS, ALLOC, LOAD, DATA Fixes: 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT section") Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-06-07Merge tag 'kbuild-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuildLinus Torvalds1-1/+1
Pull Kbuild updates from Masahiro Yamada: - Add support for the EXPORT_SYMBOL_GPL_FOR_MODULES() macro, which exports a symbol only to specified modules - Improve ABI handling in gendwarfksyms - Forcibly link lib-y objects to vmlinux even if CONFIG_MODULES=n - Add checkers for redundant or missing <linux/export.h> inclusion - Deprecate the extra-y syntax - Fix a genksyms bug when including enum constants from *.symref files * tag 'kbuild-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (28 commits) genksyms: Fix enum consts from a reference affecting new values arch: use always-$(KBUILD_BUILTIN) for vmlinux.lds kbuild: set y instead of 1 to KBUILD_{BUILTIN,MODULES} efi/libstub: use 'targets' instead of extra-y in Makefile module: make __mod_device_table__* symbols static scripts/misc-check: check unnecessary #include <linux/export.h> when W=1 scripts/misc-check: check missing #include <linux/export.h> when W=1 scripts/misc-check: add double-quotes to satisfy shellcheck kbuild: move W=1 check for scripts/misc-check to top-level Makefile scripts/tags.sh: allow to use alternative ctags implementation kconfig: introduce menu type enum docs: symbol-namespaces: fix reST warning with literal block kbuild: link lib-y objects to vmlinux forcibly even when CONFIG_MODULES=n tinyconfig: enable CONFIG_LD_DEAD_CODE_DATA_ELIMINATION docs/core-api/symbol-namespaces: drop table of contents and section numbering modpost: check forbidden MODULE_IMPORT_NS("module:") at compile time kbuild: move kbuild syntax processing to scripts/Makefile.build Makefile: remove dependency on archscripts for header installation Documentation/kbuild: Add new gendwarfksyms kABI rules Documentation/kbuild: Drop section numbers ...
2025-06-07Merge tag 'loongarch-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongsonLinus Torvalds1-1/+1
Pull LoongArch updates from Huacai Chen: - Adjust the 'make install' operation - Support SCHED_MC (Multi-core scheduler) - Enable ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS - Enable HAVE_ARCH_STACKLEAK - Increase max supported CPUs up to 2048 - Introduce the numa_memblks conversion - Add PWM controller nodes in dts - Some bug fixes and other small changes * tag 'loongarch-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: platform/loongarch: laptop: Unregister generic_sub_drivers on exit platform/loongarch: laptop: Add backlight power control support platform/loongarch: laptop: Get brightness setting from EC on probe LoongArch: dts: Add PWM support to Loongson-2K2000 LoongArch: dts: Add PWM support to Loongson-2K1000 LoongArch: dts: Add PWM support to Loongson-2K0500 LoongArch: vDSO: Correctly use asm parameters in syscall wrappers LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset() LoongArch: Preserve firmware configuration when desired LoongArch: Avoid using $r0/$r1 as "mask" for csrxchg LoongArch: Introduce the numa_memblks conversion LoongArch: Increase max supported CPUs up to 2048 LoongArch: Enable HAVE_ARCH_STACKLEAK LoongArch: Enable ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS LoongArch: Add SCHED_MC (Multi-core scheduler) support LoongArch: Add some annotations in archhelp LoongArch: Using generic scripts/install.sh in `make install` LoongArch: Add a default install.sh
2025-06-06efi/libstub: use 'targets' instead of extra-y in MakefileMasahiro Yamada1-1/+1
These objects are built as prerequisites of %.stub.o files. There is no need to use extra-y, which is planned for deprecation. Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-05-30Merge tag 'efi-next-for-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds4-7/+41
Pull EFI updates from Ard Biesheuvel: "Not a lot going on in the EFI tree this cycle. The only thing that stands out is the new support for SBAT metadata, which was a bit contentious when it was first proposed, because in the initial incarnation, it would have required us to maintain a revocation index, and bump it each time a vulnerability affecting UEFI secure boot got fixed. This was shot down for obvious reasons. This time, only the changes needed to emit the SBAT section into the PE/COFF image are being carried upstream, and it is up to the distros to decide what to put in there when creating and signing the build. This only has the EFI zboot bits (which the distros will be using for arm64); the x86 bzImage changes should be arriving next cycle, presumably via the -tip tree. Summary: - Add support for emitting a .sbat section into the EFI zboot image, so that downstreams can easily include revocation metadata in the signed EFI images - Align PE symbolic constant names with other projects - Bug fix for the efi_test module - Log the physical address and size of the EFI memory map when failing to map it - A kerneldoc fix for the EFI stub code" * tag 'efi-next-for-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: include: pe.h: Fix PE definitions efi/efi_test: Fix missing pending status update in getwakeuptime efi: zboot specific mechanism for embedding SBAT section efi/libstub: Describe missing 'out' parameter in efi_load_initrd efi: Improve logging around memmap init
2025-05-30LoongArch: Enable HAVE_ARCH_STACKLEAKYouling Tang1-1/+1
Add support for the stackleak feature. It initializes the stack with the poison value before returning from system calls which improves the kernel security. At the same time, disables the plugin in EFI stub code because EFI stub is out of scope for the protection. Tested on Loongson-3A5000 (enable GCC_PLUGIN_STACKLEAK and LKDTM): # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT # dmesg lkdtm: Performing direct entry STACKLEAK_ERASING lkdtm: stackleak stack usage: high offset: 320 bytes current: 448 bytes lowest: 1264 bytes tracked: 1264 bytes untracked: 208 bytes poisoned: 14528 bytes low offset: 64 bytes lkdtm: OK: the rest of the thread stack is properly erased Signed-off-by: Youling Tang <tangyouling@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-05-21include: pe.h: Fix PE definitionsPali Rohár1-5/+5
* Rename constants to their standard PE names: - MZ_MAGIC -> IMAGE_DOS_SIGNATURE - PE_MAGIC -> IMAGE_NT_SIGNATURE - PE_OPT_MAGIC_PE32_ROM -> IMAGE_ROM_OPTIONAL_HDR_MAGIC - PE_OPT_MAGIC_PE32 -> IMAGE_NT_OPTIONAL_HDR32_MAGIC - PE_OPT_MAGIC_PE32PLUS -> IMAGE_NT_OPTIONAL_HDR64_MAGIC - IMAGE_DLL_CHARACTERISTICS_NX_COMPAT -> IMAGE_DLLCHARACTERISTICS_NX_COMPAT * Import constants and their description from readpe and file projects which contains current up-to-date information: - IMAGE_FILE_MACHINE_* - IMAGE_FILE_* - IMAGE_SUBSYSTEM_* - IMAGE_DLLCHARACTERISTICS_* - IMAGE_DLLCHARACTERISTICS_EX_* - IMAGE_DEBUG_TYPE_* * Add missing IMAGE_SCN_* constants and update their incorrect description * Fix incorrect value of IMAGE_SCN_MEM_PURGEABLE constant * Add description for win32_version and loader_flags PE fields Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-05-21Merge branch 'efi-sbat' into efi/nextArd Biesheuvel3-2/+35
2025-05-21efi: zboot specific mechanism for embedding SBAT sectionVitaly Kuznetsov3-2/+35
SBAT is a mechanism which improves SecureBoot revocations of UEFI binaries by introducing a generation-based technique. Compromised or vulnerable UEFI binaries can be prevented from booting by bumping the minimal required generation for the specific component in the bootloader. More information on the SBAT can be obtained here: https://github.com/rhboot/shim/blob/main/SBAT.md Upstream Linux kernel does not currently participate in any way in SBAT as there's no existing policy in how SBAT generation number should be defined. Keep the status quo and provide a mechanism for distro vendors and anyone else who signs their kernel for SecureBoot to include their own SBAT data. This leaves the decision on the policy to the vendor. Basically, each distro implementing SecureBoot today, will have an option to inject their own SBAT data during kernel build and before it gets signed by their SecureBoot CA. Different distro do not need to agree on the common SBAT component names or generation numbers as each distro ships its own 'shim' with their own 'vendor_cert'/'vendor_db' Implement support for embedding SBAT data for architectures using zboot (arm64, loongarch, riscv). Put '.sbat' section in between '.data' and '.text' as the former also covers '.bss' and thus must be the last one. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-05-17x86/mm/64: Make 5-level paging support unconditionalKirill A. Shutemov1-1/+1
Both Intel and AMD CPUs support 5-level paging, which is expected to become more widely adopted in the future. All major x86 Linux distributions have the feature enabled. Remove CONFIG_X86_5LEVEL and related #ifdeffery for it to make it more readable. Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250516123306.3812286-4-kirill.shutemov@linux.intel.com
2025-05-09efi/libstub: Describe missing 'out' parameter in efi_load_initrdHans Zhang1-0/+1
The function efi_load_initrd() had a documentation warning due to the missing description for the 'out' parameter. Add the parameter description to the kernel-doc comment to resolve the warning and improve API documentation. Fixes the following compiler warning: drivers/firmware/efi/libstub/efi-stub-helper.c:611: warning: Function parameter or struct member 'out' not described in 'efi_load_initrd' Fixes: f4dc7fffa987 ("efi: libstub: unify initrd loading between architectures") Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-04-06x86/boot: Move the EFI mixed mode startup code back under arch/x86, into startup/Ard Biesheuvel2-254/+0
Linus expressed a strong preference for arch-specific asm code (i.e., virtually all of it) to reside under arch/ rather than anywhere else. So move the EFI mixed mode startup code back, and put it under arch/x86/boot/startup/ where all shared x86 startup code is going to live. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20250401133416.1436741-11-ardb+git@google.com