| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git
# Conflicts:
# mm/memblock.c
# mm/mm_init.c
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
# Conflicts:
# Documentation/scheduler/index.rst
# arch/arm64/configs/defconfig
|
|
# Conflicts:
# drivers/firmware/qcom/Kconfig
# drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
# drivers/gpu/drm/vc4/vc4_v3d.c
# drivers/soc/qcom/qcom-geni-se.c
# rust/kernel/mem.rs
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
|
|
* acpi-driver:
ACPI: bus: Drop acpi_get_first_physical_node()
efi/dev-path-parser: Switch to use acpi_bus_get_primary_device()
ALSA: hda: tas2781: Switch to use acpi_bus_get_primary_device()
ALSA: hda: cs35l41: Switch to use acpi_bus_get_primary_device()
iommu/arm-smmu-v3: Switch to use acpi_bus_get_primary_device()
ACPI: Add stub for acpi_find_child_device()
ACPI: bus: Provide !ACPI stub for acpi_device_uid()
ALSA: hda: aw88399: Switch to use acpi_bus_get_primary_device()
ASoC: loongson: Switch to use acpi_bus_get_primary_device()
ASoC: intel: boards: Switch to use acpi_bus_get_primary_device()
ASoC: amd: acp3x-es83xx: Switch to use acpi_bus_get_primary_device()
ASoC: amd: acp-es8336: Switch to use acpi_bus_get_primary_device()
thunderbolt: Switch to use acpi_bus_get_primary_device()
platform/x86: apple-gmux: Switch to use acpi_bus_get_primary_device()
platform/x86: x86-android-tablets: Use acpi_bus_get_primary_device()
platform/x86: serdev_helpers: Switch to use acpi_bus_get_primary_device()
platform/x86: yogabook: Switch to use acpi_bus_get_primary_device()
ACPI: amba: Switch to use acpi_bus_get_primary_device()
ACPI: bus: Use acpi/acpi_bus.h without CONFIG_ACPI
|
|
Since commit 48ebe1cbbeb51 ("kbuild: compress the kernel with pigz if
available"), cmd_gzip runs pigz through scripts/jobserver-exec, which
takes the job slots make has free. GNU Make passes the jobserver pipe
only to recipes it treats as recursive, but leaves --jobserver-auth in
MAKEFLAGS for all of them. The make 4.3 in CentOS Stream 9 also hides
the pipe in sub-makes (a backport of the fix for GNU Make bug 58232), so
jobserver-exec cannot open it, runs pigz on one thread, and prints:
WARNING: Unable to reopen jobserver read-side pipe: FileNotFoundError(2, 'No such file or directory')
Mark every recipe that can run cmd_gzip as recursive with "+", as
commit ecab4115c44cc ("kbuild: mark `rustc` (and others) invocations as
recursive") did for rustc. Besides the $(call if_changed,gzip) rules,
this covers those that choose gzip through a variable: the built-in
initramfs in usr/Makefile (which rcutorture's kvm.sh builds), the EFI
zboot image, and the arm, csky, and mips compressed images. As with
rustc, "make -n" now runs these recipes, including those that choose
through a variable when they select another compressor. Also update the
gzip entry in Documentation/kbuild/makefiles.rst, as suggested in
review.
Tested with GNU Make 4.3 plus CentOS Stream 9's make-4.3-cloexec.patch,
GCC 16.2.0, and -j64, on ARCH=x86_64, arm64, and arm defconfig, and
ARCH=x86_64 defconfig with a built-in initramfs: none of them prints the
warning, and pigz gets the free job slots (-p 54, 64, and 50 for the
kernel image). Without this change, the x86_64 builds print it for the
kernel image and for the initramfs.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Closes: https://lore.kernel.org/all/0ddb5e5e-f801-444c-aa98-0cfe814a3026@paulmck-laptop/
Fixes: 48ebe1cbbeb51 ("kbuild: compress the kernel with pigz if available")
Assisted-by: LLM
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Kees Cook <kees@kernel.org>
Tested-by: Paul E. McKenney <paulmck@kernel.org>
Link: https://patch.msgid.link/20261010081914.540611-1-kees@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
|
|
Commit 4b2c033b5bc9 ("efi/runtime-wrappers: retire the worker if a wedged
call ever returns") parks the efi_rts_wq worker instead of completing the
call if EFI runtime services have been disabled by the time the firmware
returns. The assumption is that this only happens if __efi_queue_work()
has given up waiting for the call.
However, arm64 also disables EFI runtime services when it recovers from a
synchronous exception taken by the firmware: efi_runtime_fixup_exception()
clears EFI_RUNTIME_SERVICES and unwinds the call so that it returns
EFI_ABORTED to efi_call_rts(), while the caller is still waiting for the
completion. The worker now parks without signalling it, so the caller is
stuck for the full EFI_RTS_TIMEOUT of 120 seconds, after which it reports
that the firmware is wedged, which is misleading.
x86 is not affected, as it signals the completion from its page fault
handler before parking the worker.
So record explicitly that the caller has given up on the call, and only
park the worker in that case.
Fixes: 4b2c033b5bc9 ("efi/runtime-wrappers: retire the worker if a wedged call ever returns")
Cc: Breno Leitao <leitao@debian.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The term "KHO scratch" is vague and overloaded.
For one, it does not accurately describe what the memory is for. From
KHO's perspective, it is memory passed by the previous kernel that is
guaranteed to have no allocations and hence it is safe to allocate from.
For another, the term is overloaded. KHO also knows to discover other
ranges of memory that don't have any preservations and are safe to
allocate from. This is done by kho_extend_scratch(). These areas, while
called "scratch", are completely different from the chunk of memory
passed by the previous kernel for early boot allocations.
Rename "KHO scratch" to "KHO boot memory", or "KHO bootmem" in short.
Update all function names, variable names, comments, and documentation
to use this.
Call the discovered areas "noprsrv", matching what memblock would see
them as. Rename kho_extend_scratch() to reflect this.
This patch largely has no functional changes. The only functional
changes are renames of debugfs files from "scratch_phys" and
"scratch_len" to "bootmem_phys" and "bootmem_len" respectively.
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Link: https://patch.msgid.link/20260922041321.233986-4-pratyush@kernel.org
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
The term "KHO scratch" is vague. It does not accurately describe what
the memory is for. Generally, scratch is for things that don't contain
anything useful. This is not true.
For memblock, KHO_SCRATCH is the _only_ useful memory during a KHO boot.
It is memory passed by the previous kernel that is guaranteed to have no
preserved pages, and so is the only thing safe to allocate from early in
boot.
In addition, KHO now has the ability to discover other "scratch" areas.
These aren't directly passed by the previous kernel. Instead, they are
found by searching the KHO preserved memory map.
Memblock does not care about the difference between the two. From
memblock's perspective, both are memory areas with no preservations and
so they are safe to allocate from before KHO fully initializes.
Rename MEMBLOCK_KHO_SCRATCH to MEMBLOCK_KHO_NOPRSRV. This name clearly
shows what the memory is for from memblock's perspective. Update
memblock functions and comments that refer to scratch to use noprsrv.
There are no functional changes apart from the flag name change in
debugfs.
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
Link: https://patch.msgid.link/20260922041321.233986-3-pratyush@kernel.org
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
Use sysfs_emit() where appropriate to generate the contents of EFI
related sysfs nodes. This is a more robust wrapper around sprintf()
designed for this purpose.
Reported-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Implement Thomas's suggestions to constify sysfs kobject attributes.
Cc: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Every architecture that builds the stub now adds $(DISABLE_KSTACK_ERASE)
to its own flags, so add it once to the flags they share instead.
Assisted-by: LLM
Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The x86 stub replaces KBUILD_CFLAGS with a short list of its own, so new
kernel-wide compiler options go missing, unless explicitly remembered
or when lacking them breaks the build, e.g. commit 5ff8ad3909524
("kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS")
did. Today, several still go missing that are provided to non-x86
stub builds, e.g. -ftrivial-auto-var-init, -fzero-call-used-regs,
-fstrict-flex-arrays=3, and the various kernel's warnings.
Flip the x86 option logic to match the other architectures. Since the
x86 stub is linked into the decompressor rather than the kernel proper,
remove the kernel code model, the i386 register calling convention,
and the kernel's reduced stack alignment, along with the retpoline and
return thunks and the call padding, which only the kernel provides,
and disable kernel stack erasing as the other architectures do. The
existing -mcmodel=small, -march=i386, and -fPIC still get overrides.
Build with -fcf-protection=none, since nothing enables IBT while the
stub runs: the firmware applies forward-edge CFI only to images that
advertise it, which bzImage does not.
New flags that change code generation or semantics in a plain x86_64
defconfig hardening.config stub:
Hardening:
-ftrivial-auto-var-init=zero
-fzero-init-padding-bits=all
-fstrict-flex-arrays=3
-fno-strict-overflow
-fno-delete-null-pointer-checks
-fno-allow-store-data-races
-fno-jump-tables (from the default IBT config)
C semantics:
-funsigned-char
-fno-common
x86 code generation:
-mno-sse2 -mno-3dnow -mno-avx -mno-sse4a
(stub already added -mno-mmx -mno-sse)
-mno-80387 -mno-fp-ret-in-387 -mskip-rax-setup
-falign-jumps=1 -falign-loops=1 -fmin-function-alignment=16
-fomit-frame-pointer -fconserve-stack
-fno-stack-clash-protection -fno-stack-check -fno-builtin-wcslen
Warnings (lots and lots, but notably):
-Wall -Wextra -Wundef -Wmissing-prototypes
-Wvla-larger-than=1 -Wimplicit-fallthrough=5
Present but with no effect, because the stub's later flags override them:
-O2, overridden by -Os
-fstack-protector-* flags, overridden by -fno-stack-protector
-fno-PIE, overridden by -fPIC
-fcf-protection=branch, overridden by -fcf-protection=none
the stack-erase plugin, loaded and then disabled
Build tested ARCH=x86_64 defconfig hardening.config, plus retpolines,
return thunks, call depth tracking, IBT, GCC plugins, and EFI mixed
mode, with GCC 16.2.0 and Clang 24.0.0git, and ARCH=i386 defconfig
hardening.config with GCC 16.2.0. Each booted through the EFI stub to
userspace under QEMU with x64 and IA32 OVMF, the latter in mixed mode
for x86_64.
Assisted-by: LLM
Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
efi_stub_entry() and efi_handover_entry() are entered from efi-mixed.S
and, through the efi32_stub_entry() and efi64_stub_entry() aliases, by
boot loaders using the EFI handover protocol, but have no prototypes.
Declare them in x86-stub.h, as asmlinkage, so that the stub can be built
with the kernel's -Wmissing-prototypes.
Assisted-by: LLM
Signed-off-by: Kees Cook <kees@kernel.org>
[ardb: fix i386 GCC build by scoping to CONFIG_EFI_MIXED=y]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Sashiko points out that efi_handle_cmdline() allocates this memory and
hands it over to the caller. If efi_pe_entry() ever returns it should be
freed. Add a __free annotation.
Fixes: 42c8ea3dca09 ("efi: libstub: Factor out EFI stub entrypoint into separate file")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Sashiko points out the image_size should only be set if image_addr was
reassigned to some allocated memory. If image_size is not zero then the
caller will free the image_addr pointer.
efi_kaslr_relocate_kernel() never works like that, if it changes
image_addr to allocated memory the free is done through reserve_size.
Fixes: b7ac4b8ee73d ("riscv: libstub: Implement KASLR by using generic functions")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Sashiko says fdt_addr can point to either an allocated fdt or the fdt from
get_fdt() which is memory owned by FW.
Only the allocated fdt should be freed on the error unwind path. Use a
dedicated variable for the allocation's size so that the free does not get
confused.
Fixes: 4fc8e738ff3e ("efi: libstub: remove DT dependency from generic stub")
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
|
|
The Boot Loader Interface (BLI) [1] defines EFI variables that expose
boot loader state to the running OS. LoaderInfo identifies the boot
loader, while LoaderDevicePartUUID records the GPT partition UUID of
the partition containing it.
LoaderDevicePartUUID is used, for example, by systemd-gpt-auto-generator
[2] to identify the disk the boot loader was launched from and
automatically detect and mount partitions on it.
GRUB [3] and systemd-boot [4] populate these variables, but when the
kernel is started directly by EFI firmware, there is no conventional
external boot loader to provide them. In that case, because the EFI stub
performs the boot loader role, it should provide the variables itself.
Use LoaderInfo as a sentinel: if it is already set by an earlier boot
stage or cannot be set, bail out. Otherwise, populate the other BLI
variables.
Parse the loaded image device path, extract the GUID signature from its
GPT HD() node and publish it under the Linux loader entry vendor GUID as
the volatile LoaderDevicePartUUID EFI variable.
Install the efi_bli_set_variables() hook in both the generic efi-stub.c
path and the x86-specific x86-stub.c path.
[1] The Boot Loader Interface
Link: https://systemd.io/BOOT_LOADER_INTERFACE/
[2] systemd-gpt-auto-generator
Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
[3] GRUB -- §16.2 bli
Link: https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html
[4] systemd -- systemd-boot UEFI Boot Manager
Link: https://github.com/systemd/systemd/blob/main/docs/BOOT.md?plain=1#L102
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
[ardb: - constify 'image' pointer parameter
- pass efi_guid_t* to efi_snprintf()]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The native EFI character set is UTF-16 (or in practice, UCS-2).
Implement efi_snprintf() to construct UTF-16 strings using printf style
templates. This will be used in a subsequent patch to set the
LoaderDevicePartUUID EFI variable.
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Add support for the %pUl printk conversion specifier, which takes a
pointer to a GUID and prints it in the usual format:
aaaaaaaa-bbbb-cccc-dddd-dddddddddddd
Co-developed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The only remaining users of vsnprintf() in the EFI stub are the
diagnostic printk()'s, which are emitted to the console and not recorded
for posterity.
The EFI console uses UTF-16 (or actually, UCS-2) natively, and so all
non-UTF16 strings that are emitted need to be converted. Given the
stub's vsnprintf() support for wide strings (using the %ls conversion
modifier), which uses UTF-16 to UTF-8 conversion internally, the final
conversion to UTF-16 needs to support not just plain ASCII but UTF-8 as
well.
This is all pointless, of course, and it makes more sense to use UTF-16
internally. This removes the need for UTF-16 to UTF-8 conversion in
vsnprintf(), and given that all non-wide string inputs to vsnprintf()
that exist in the stub today are compile time constant ASCII strings,
the need to convert UTF-8 to UTF-16 disappears as well.
So implement efi_vsnprintf() taking a const char *fmt as before, but
outputting a efi_char16_t[] that can be passed to the EFI console
directly, rather than via efi_puts(), leaving the latter unused and
therefore removed.
Note that efi_puts() performs LF to CR-LF conversion internally, so add
this capability to efi_vsnprintf() as well.
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
efi_puts() performs a UTF-8 to UTF-16 conversion on its input, as the
EFI console's native character set is UTF-16.
This is pointless for compile time constant strings, since we can
simply define those as UTF-16 to begin with. This takes slightly more
space, but removes any runtime handling of those strings, simplifying
the code.
Note that efi_puts() also performs LF to CR-LF conversion, so this needs
to be taken into account as well.
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Don't rely on sprintf() with a wide string conversion modifier to
convert the command line from UTF-16 to UTF-8. Instead, use the
existing ucs2 string library routine that does the same. Note that while
UEFI claims support for UTF-16, in practice it ignores surrogate pairs
entirely, and so the simplified UCS-2 character set (where each
character takes up exactly 2 bytes) is sufficient here.
This removes the only user of sprintf() in the EFI stub, so drop that
function as well.
Since boot memory is plentiful on UEFI systems, just establish a worst
case upper bound for the size of the buffer (which can never exceed
COMMAND_LINE_SIZE), and allocate that first. Then, perform the
conversion, and only fall back to processing the command line character
by character if that resulted in truncation. This makes the common
execution path much simpler.
Note that this no longer truncates the command line at the first
newline, but there is no evidence that this has ever been needed.
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Replace acpi_get_first_physical_node() that is slated for removal
with acpi_bus_get_primary_device() that takes a reference to the
device it is about to return.
This addresses a potential use-after-free that may occur if the
device returned by acpi_get_first_physical_node() is removed right
after dropping its ACPI companion's physical_node_lock in that
function.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/3974502.kQq0lBPeGt@rafael.j.wysocki
|
|
arch_accept_memory() is an arch-specific hook that is required by the
EFI stub when processing memory that the firmware reports to the OS as
EFI_UNACCEPTED_MEMORY.
This hook is called after ExitBootServices() has been called, as before
that point, the EFI memory map may get updated behind the back of the
running EFI stub, making it difficult to get a stable view on it while
iterating over the entries.
Currently, the x86 version of this hook is implemented in its
decompressor rather than in the EFI stub itself, in a manner that is
problematic: when an error occurs, it calls the decompressor's error()
routine, but without having gone through the decompressor initialization
code. This means it will resort to direct port I/O rather than the
hypercall based interface that TDX guests would use otherwise.
Conceptually, code that is only called from the EFI stub, and never by
the decompressor when doing legacy boot, belongs in the EFI stub and not
in the decompressor.
So move it into the x86-specific EFI stub code, replacing the error() on
the TDX path with tdx_panic(), and dropping the error() when no CC
support is detected - the kernel can decide what to do in this case
after it has booted.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Link: https://patch.msgid.link/20260925075137.44298-7-ardb@kernel.org
|
|
Each kernel make invocation begins with ~30 compiler and linker runs each
of which performs duplicate probe for a number of compiler and linker
options.
This is useless work - the compiler and its version is known, so use these
to determine which options are available, once.
Using the newly introduced cc-option-str, track the result of each probe in
CC_OPT_*, LD_OPT_* variables and have Makefile's simply append the symbol.
Some care has to be taken around negative options, i.e. -Wno-xxx, as gcc
accepts an unknown -Wno- without complaint and only complains later, so
instead probe the positive form for these cases.
Use CC_HAS_* For those probes that gate a Makefile conditional rather than
a simple option, as per the established pattern for this.
This change avoids a subtle issue with ppc32 (big endian) - clang doesn't
accept -fno-stack-clash-protection on this sub-target, so keep this option
in the Makefile.
With gcc and clang, defconfig and allmodconfig, the recorded command
lines are unchanged, a build with nothing to do rebuilds nothing and W=1
continues to function correctly.
Doing this improves all builds, but has a particularly positive impact on
no-op builds (builds where nothing has changed).
Whole build, 128-thread Threadripper 9980X, best of N runs:
before after delta
-------------------------------
x86 defconfig, no-op make, gcc 0.78s 0.60s -0.18s (-23%)
x86 defconfig, no-op make, clang 0.94s 0.66s -0.28s (-30%)
x86 defconfig, touch mm/vma.c, gcc 8.6s 8.5s -0.16s (-2%)
x86 defconfig, touch mm/vma.c, clang 8.0s 7.7s -0.24s (-3%)
x86 defconfig, clean, clang 29.8s 29.4s -0.37s (-1%)
x86 allmodconfig, no-op make, gcc 12.9s 12.7s -0.23s (-2%)
x86 allmodconfig, no-op make, clang 14.2s 13.9s -0.29s (-2%)
x86 allmodconfig, touch mm/vma.c, clang 32.2s 31.9s -0.30s (-1%)
Assisted-by: LLM
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260923-build-speedup-v4-12-73128809a4a4@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
|
|
The Lenovo D330 is a notebook with detachable display. The display
is installed in landscape orientation, but the display mode is in
portrait orientation. By default, the display output is rotated to
the left by 90°.
The sysfb quirk breaks the display by swapping display width and
height; and thus mixing up the display geometry. Fix this by keeping
the display as-is. The sysfb DRM drivers, usually efidrm, will pick
the correct panel orientation for the display.
The exact behavior might depend on the version of the BIOS release,
but the exact version numbers of broken and good releases are unknown.
Users are advised to update to the latest firmware.
Tested on a Lenovo D330-10IGM IdeaPad with firmware 8NCN43WW.
v3:
- mention possible dependency on BIOS release in commit description
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260904090850.43060-2-tzimmermann@suse.de
|
|
Fix the grammar in the kernel-doc comment and indent the @image_addr
description correctly.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Drop the local ret variable and the break statement by returning the
result directly. Also use unsigned long for map_offset, since map_size
and desc_size are both unsigned long.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
alloc_e820ext() and setup_e820() use sizeof(struct e820_entry) when
calculating the sizes of boot_e820_entry structures.
Even though struct e820_entry and struct boot_e820_entry have the same
size, use sizeof(struct boot_e820_entry) for consistency instead.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
kmap() is deprecated in favour of kmap_local_page(), as described in
Documentation/mm/highmem.rst.
The conversion is safe here. efi_capsule_write() maps the page and
releases it within the same call, on both the success and the fail_unmap
error path, so the mapping never escapes the thread that created it and
the stack-based unmap ordering is preserved. No atomic context is
involved: the page is allocated with alloc_page(GFP_KERNEL) just above,
and the copy_from_user() performed while the page is mapped is fine
because faults are permitted in a local kmap region.
efi_capsule_setup_info() also runs while the mapping is live, but only
reads through the pointer.
kunmap_local() is handed a pointer that has been advanced into the page,
which is fine as it masks the address back down to the page boundary.
Build-tested only, on i386 with CONFIG_HIGHMEM=y -- where
kmap_local_page() actually establishes a mapping rather than returning
the direct-map address -- and on x86_64. No new gcc or sparse warnings.
Assisted-by: LLM sparse
Signed-off-by: Danish Khateeb <danishkhateeb03@gmail.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Correct "existance" to "existence", reported by scripts/checkpatch.pl using
the misspelling list in scripts/spelling.txt. Only touches comments, no
code changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
efi_set_event_at() documents ids although its array index argument is
named idx. This produces missing and excess parameter warnings.
Match the argument name and fix the adjacent spelling of array.
Fixes: 8c0a839c2bcc ("efi/libstub: Descriptions for stub helper functions")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
cper_mem_err_pack() copies extended, rank, mem_array_handle and
mem_dev_handle unconditionally. Those live at offsets 73 to 79, past the
end of struct cper_sec_mem_err_old, the 73-byte UEFI 2.1/2.2 layout that
older firmware still emits and that cper_estatus_print_section() admits.
On such a record the copy reads up to seven bytes past the payload, and off
the end of the error status block when that section is the last one.
Copy each of the four only when its validation bit is set, and zero it
otherwise. Nothing is lost: a 2.1/2.2 record leaves those bits clear, and
every consumer of struct cper_mem_err_compact already gates the fields on
the same bits. Zeroing also stops callers reading them back out of the
uninitialised on-stack struct they pass in.
Reported-by: sashiko-bot@kernel.org
Closes: https://sashiko.dev/#/patchset/20260714231835.303081-1-dave.jiang@intel.com?part=7
Fixes: 2dfb7d51a61d ("trace, RAS: Add eMCA trace event interface")
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-11-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
cper_estatus_len() sums the firmware-controlled data_length (or
raw_data_offset plus raw_data_length) into a u32. A data_length of
0xffffffec wraps that sum to 0, and a length that reads back short defeats
every bound built on it: bert_print_all() passes its "remain <
estatus_len" check, then advances "estatus += estatus_len" by zero and
loops forever. GHES survives only because __ghes_check_estatus() rejects a
length below sizeof(*estatus) first.
Reject a length that cannot be expressed in a u32 in
cper_estatus_check_header(), which both of today's callers reach: GHES via
__ghes_check_estatus() and BERT via cper_estatus_check(). extlog reaches
neither yet; a later patch routes it through cper_estatus_check(), whose
ELOG_ENTRY_LEN bound needs this to hold.
Reported-by: sashiko-bot@kernel.org
Closes: https://sashiko.dev/#/patchset/20260714231835.303081-1-dave.jiang@intel.com?part=1
Fixes: 06d65deade9a ("ACPI, APEI, UEFI Common Platform Error Record (CPER) header")
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-3-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
cper_estatus_check() sizes each section with acpi_hest_get_record_size(),
which adds the firmware-controlled u32 error_data_length to the header size
as a signed int (see <acpi/ghes.h>). A value in the top sizeof(*gdata)
bytes of the u32 range wraps the sum small rather than large, so it slips
past the "record_size > data_len" check: against the 72-byte v300 header,
0xffffffb9 sizes the record at 1 and acpi_hest_get_next() walks it a byte
at a time, off the end. 0xffffffb8 sizes it at 0 and loops forever.
Use check_add_overflow() to reject a sum that will not fit the int those
helpers return, since the walk advances by that value. That subsumes the
"acpi_hest_get_size(gdata) > data_len" test above it, because record_size
is never smaller than the header.
The later "len < sizeof(*foo)" guards rely on this per-section upper bound;
they are lower bounds only.
Reported-by: sashiko-bot@kernel.org
Closes: https://sashiko.dev/#/patchset/20260714231835.303081-1-dave.jiang@intel.com?part=1
Fixes: 45b14a4ffcc1 ("efi: cper: Fix possible out-of-bounds access")
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-2-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Some GUIDs are used several times in the same translation unit.
Factor the duplicated EFI_FILE_SYSTEM_GUID, EFI_RNG_PROTOCOL_GUID and
EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID objects at file scope within their
translation units. Leave the single-use GUID objects at function scope.
For an x86_64 build with gcc 15.3.0, bloat-o-meter reports:
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-48 (-48)
Function old new delta
rng_proto 32 16 -16
graphics_output_guid 32 16 -16
fs_proto 32 16 -16
Total: Before=28471, After=28423, chg -0.17%
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Local efi_guid_t variables with automatic storage produce assembly
similar to passing the address of the GUID macro directly. For the same
reason, make these GUID variables static.
Put the static declarations first in their local declaration block to
visually separate them from the automatic variables.
For an x86_64 build with gcc 15.3.0, bloat-o-meter reports:
add/remove: 15/0 grow/shrink: 0/10 up/down: 336/-742 (-406)
Function old new delta
tbl_guid - 32 +32
rng_proto - 32 +32
pci_proto - 32 +32
guid - 32 +32
fs_proto - 32 +32
cc_guid - 32 +32
tpm2_guid - 16 +16
text_to_dp_guid - 16 +16
tcg2_guid - 16 +16
rng_table_guid - 16 +16
rng_algo_raw - 16 +16
proto - 16 +16
linux_eventlog_guid - 16 +16
lf2_proto_guid - 16 +16
info_guid - 16 +16
efi_get_memory_map 707 696 -11
efi_pci_disable_bridge_busmaster 1199 1184 -15
efi_get_random_bytes 216 188 -28
efi_remap_image 357 328 -29
efi_load_initrd 1113 1065 -48
efi_random_get_seed 1368 1297 -71
efi_measure_tagged_event 935 854 -81
efi_retrieve_eventlog 1686 1570 -116
handle_cmdline_files 2501 2341 -160
efi_stub_entry 4136 3953 -183
Total: Before=28877, After=28471, chg -1.41%
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Some EFI stub call sites pass the address of a GUID macro directly to
EFI boot services. With gcc, this makes the compiler materialize the
GUID data at the call site, which is wasteful in the size-sensitive EFI
stub.
For example, consider this program:
#include <linux/efi.h>
#define GUID \
EFI_GUID(0xaaaaaaaa, 0xbbbb, 0xcccc, \
0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd)
void foo(const efi_guid_t *guid);
void guid_direct(void)
{
foo(&GUID);
}
void guid_static(void)
{
static efi_guid_t guid = GUID;
foo(&guid);
}
For guid_direct(), gcc materializes the GUID on the stack:
0: f3 0f 1e fa endbr64
4: 48 b8 aa aa aa aa bb movabs $0xccccbbbbaaaaaaaa,%rax
b: bb cc cc
e: 48 83 ec 18 sub $0x18,%rsp
12: 48 89 04 24 mov %rax,(%rsp)
16: 48 89 e7 mov %rsp,%rdi
19: 48 b8 dd dd dd dd dd movabs $0xdddddddddddddddd,%rax
20: dd dd dd
23: 48 89 44 24 08 mov %rax,0x8(%rsp)
28: e8 00 00 00 00 call 2d <guid_direct+0x2d>
2d: 48 83 c4 18 add $0x18,%rsp
31: c3 ret
For guid_static(), gcc stores the GUID in .data and emits a RIP-relative
address load:
32: f3 0f 1e fa endbr64
36: 48 8d 3d 00 00 00 00 lea 0x0(%rip),%rdi
3d: e9 00 00 00 00 jmp 42 <guid_static+0x10>
Overall, guid_direct() consumes 50 bytes in the .text segment whereas
guid_static() needs only 32 bytes in total: 16 bytes in .data and 16
bytes in .text.
Move these direct GUID references to function-local static objects and
pass their address instead. EFI boot service prototypes take non-const
efi_guid_t pointers, so keep the GUID non-const to prevent a
-Wdiscarded-qualifiers warning.
For an x86_64 build with gcc 15.3.0, bloat-o-meter reports:
add/remove: 6/0 grow/shrink: 0/3 up/down: 112/-458 (-346)
Function old new delta
graphics_output_guid - 32 +32
smbios_guid - 16 +16
edid_discovered_guid - 16 +16
edid_active_guid - 16 +16
console_out_device_guid - 16 +16
apple_set_os_guid - 16 +16
efi_stub_entry 4180 4136 -44
efi_get_smbios_record 283 226 -57
efi_setup_graphics 2210 1853 -357
Total: Before=29223, After=28877, chg -1.18%
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Add an interface for PREEMPT_RT kernels to dynamically enable or
disable EFI runtime services.
EFI runtime services are typically disabled on RT systems using
kernel parameters such as "noefi" or "efi=disable" to avoid
long latency caused by firmware calls. However, this permanently
disables EFI runtime services, preventing operations such as UEFI
firmware updates.
With this change, EFI runtime services can be disabled while
real-time workloads are running and re-enabled afterwards,
providing low-latency operation without permanently sacrificing
firmware functionality.
Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
kmap_atomic() is deprecated in favour of kmap_local_page(), as described
in Documentation/mm/highmem.rst.
The conversion is safe here: the mapping is created and torn down within a
single iteration of the sg_count loop, preserving the strict stack-based
ordering that kmap_local_page() requires, and the mapped region is only
written to, so neither pagefault_disable() nor preempt_disable() is needed.
The surrounding code already sleeps (it allocates the pages with
alloc_page(GFP_KERNEL) and later takes capsule_mutex), so there is no
atomic context to preserve.
Build-tested only.
Assisted-by: LLM sparse
Signed-off-by: Danish Khateeb <danishkhateeb03@gmail.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
map_properties() remaps the Apple properties setup_data payload
and then reads the properties header fields.
Reject a truncated payload before checking the header version and length
fields.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
When __efi_queue_work() times out it disables runtime services and
returns, but the kworker is still blocked inside firmware. If the
firmware eventually unblocks, efi_call_rts() would run its tail on an
efi_rts_work that the timed-out caller has long abandoned: signalling a
stale completion and clearing efi_runtime_lock_owner that may by then
belong to another caller.
If runtime services have been disabled by the time the call returns,
park the worker with efi_rts_park_worker() instead, so it never touches
efi_rts_work again or returns to the workqueue.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Three wrappers call firmware directly instead of going through
__efi_queue_work(), and none of them check whether runtime services are
still enabled: virt_efi_set_variable_nb(),
virt_efi_query_variable_info_nb() and virt_efi_reset_system(). Once a
hang has cleared EFI_RUNTIME_SERVICES - or efi_recover_from_page_fault()
has cleared it on a firmware page fault - these paths still enter the
(possibly wedged) firmware, e.g. an EFI pstore write through the
non-blocking SetVariable() variant, in violation of UEFI's
non-reentrancy rules. reset_system() is reachable too: efi_reboot()
only gates it on the static efi_rt_services_supported() mask, which does
not track the runtime disable.
Check efi_enabled(EFI_RUNTIME_SERVICES) in each before calling into
firmware. Test it after taking efi_runtime_lock rather than before: the
bit is only ever cleared at runtime while that lock is held, so checking
it under the lock avoids racing with a concurrent timeout that clears the
bit and drops the lock.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
When an EFI runtime service hangs in firmware, the efi_rts_wq worker is
stuck inside the call and cannot be cancelled. __efi_queue_work() then
waits on the completion forever while holding efi_runtime_lock, so every
later EFI caller is wedged until reboot; the only symptom is a "workqueue
lockup" and tasks piling up on the semaphore.
Replace wait_for_completion() with wait_for_completion_timeout() bounded
by EFI_RTS_TIMEOUT (120 seconds). On timeout, clear EFI_RUNTIME_SERVICES
and return EFI_ABORTED so later callers fail fast at the entry check
instead of each paying another 120 seconds. The wedged worker is
intentionally leaked and keeps ownership of efi_rts_work.
A worker that only starts running after the timeout would otherwise
dereference efi_rts_work.args, now pointing into the caller's freed stack
frame, and hand stale pointers to firmware. Park it with
efi_rts_park_worker() at the entry of efi_call_rts() when runtime
services are already disabled, before it touches args or enters firmware.
Known limitation: a worker already inside firmware when the timeout fires
still holds efi_rts_args pointing into the caller's stack frame; if
firmware unblocks afterwards and writes the output buffers, they land in
reused memory. Firmware hung this long rarely recovers; a follow-up could
bounce the buffers through kmalloc.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Move the EFI_RUNTIME_SERVICES check to the top of __efi_queue_work() and
return directly, so a caller that finds runtime services disabled returns
without touching the shared efi_rts_work. No functional change.
This prepares for bounding the wait, where a timeout will clear
EFI_RUNTIME_SERVICES while the leaked worker still owns efi_rts_work; a
later caller must then bail out before reinitialising it.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Convert the queue_work() failure path in __efi_queue_work() to a
goto exit instead of falling through to the wait and the
WARN_ON_ONCE(status == EFI_ABORTED) below it. A failed queue_work()
leaves the status at its initial EFI_ABORTED, so that warning would
fire even though no call ran; it is meant for a completed call that
returned EFI_ABORTED.
No change for the common (successful enqueue) path. This also prepares
__efi_queue_work() for the timeout handling added later.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
x86's efi_crash_gracefully_on_page_fault() ends in an infinite
schedule() loop so the kworker that faulted in firmware never runs
efi_rts_wq again. A later change needs the same "park this worker
forever" primitive on the runtime service timeout path, so factor the
loop into a shared efi_rts_park_worker() and call it from the x86
page-fault handler.
No functional change.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
