| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
# Conflicts:
# drivers/firmware/efi/libstub/Makefile
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git
# Conflicts:
# mm/memblock.c
# mm/mm_init.c
|
|
# Conflicts:
# drivers/firmware/qcom/Kconfig
# drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
# drivers/gpu/drm/drm_panic.c
# drivers/gpu/drm/vc4/vc4_v3d.c
# drivers/soc/qcom/qcom-geni-se.c
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI support updates from Rafael Wysocki:
"The most significant change here is the rework of the core ACPI device
enumeration code to avoid initializing ACPI power management
prematurely for devices with unmet dependencies. This essentially is a
problem fix, but it requires taking PCI device enumeration ordering
into account among other things, so it is far from straightforward.
There was an attempt to do this in the 7.3 time frame that had to be
reverted, so this time it is done much more carefully.
There is also an ACPI thermal control update rearranging the code to
register thermal class cooling devices under specific parents, which
is visible in sysfs. This helps to figure out what is represented by
those devices much more easily, but it also allows the binding of
cooling devices to trip points in thermal zones to be adjusted so it
need not rely on specific cooling device data usage in thermal
drivers.
From the number of commits perspective, the most visible part is the
one replacing acpi_get_first_physical_node() with
acpi_bus_get_primary_device() everywhere and dropping the former that
was inherently racy and generally unsafe to use. Fortunately, the
maintainers involved responded timely and all of that could be done
within one development cycle.
Another quite visible part is Dave Jiang's series fixing multiple
issues reported by Sashiko in the ACPI APEI support code with a PCI
AER improvement on top. It took several iterations of this to make
Sashiko happy and the code in question should be much more robust
going forward.
One other thing worth mentioning separately is that the ACPI bus type
is now going to be registered as a "companion" one and it will not be
possible to register a driver binding directly to a struct
acpi_device. All of the existing users of those drivers in the tree
were converted to platform drivers in the previous cycles, so this is
just a final step in a longer journey.
Apart from the above, there are many fixes, mostly in drivers, with a
noticeable exception of a fix in the code binding devices to their
ACPI companions, new IOVT IOMMU support in ACPICA, new _Ixx object
support for suspend-to-idle on x86, multiple new quirks, mostly
related to unused ACPI power resources and backlight handling, and
assorted cleanups.
Specifics:
- Make the core ACPI device enumeration code stop attempting to
initialize ACPI power management for devices before they are known
to be present and functional (Rafael Wysocki)
- Simplify and clean up the core ACPI device enumeration code on top
of the previous adjustment and reduce debug noise coming from it
(Rafael Wysocki)
- Fix locking in the code binding devices to their ACPI companions,
prevent it from replacing a valid ACPI companion pointer with NULL
incidentally, improve its messaging (including debug noise
reduction), and reduce its overhead by making it skip the cases in
which no ACPI companion may exist early (Rafael Wysocki)
- Reduce runtime memory footprint of struct acpi_device by
rearranging fields in it (Andy Shevchenko)
- Update the driver core to allow bus types without drivers to be
registered as "companion bus types" without driver-related sysfs
attributes and register the ACPI bus type as a companion one
(Rafael Wysocki)
- Use strscpy() instead of strcpy() in the ACPI sysfs interface
(Ruslan Vagner)
- Remove __meminitdata from hmat_adist_nb declaration preserving it
even when CONFIG_MEMORY_HOTPLUG is not set to prevent notifier
chain corruption in some cases (Alejandro Lucero)
- Prevent a NULL pointer dereference when attempting to read the
table length after a mapping bookkeeping failure during an initrd
override invocation with permanent table mappings enabled (Slavin
Liu)
- Use for_each_populated_zone() in get_node_num() in the MRRM table
pareser (Sang-Heon Jeon)
- Use vsnprintf() in acpi_os_vprintf() to prevent memory corruption
resulting from overly long diagnostic messages that may not fit
into a static buffer used by ACPICA and may be produced by a
malformed ACPI table (Vlatko Kosturjak)
- Ignore leading root scope prefix in string _UID match to allow AMD
IOMMU matching to work as expected in some cases (Mario
Limonciello)
- Adjust message printing macros for ACPI objects to use dev_fmt()
for more consistency with the analogous dev_*() macros (Rafael
Wysocki)
- Add _Ixx GPE wake indicator support to the x86 suspend-to-idle
handling code (Saranya Gopal)
- Clear driver_data before free in the ACPI PCI Link driver to
prevent a dangling pointer from being used later (Jiale Yao)
- Accumulate the queued flag across error sections of a CPER record
in ghes_do_proc() to prevent it from being cleared by a later
section or entry that does not queue memory-failure work (Breno
Leitao)
- Map a raw PCI AER Capability image field by field to prevent
information loss from occurring while processing it (Dave Jiang)
- Update a stale driver source reference in the ACPI APEI EINJ driver
documentation (Prabhakar Pujeri)
- Reject CPER records with an out-of-range error_data_length or an
error status block length wrapping a u32 in the EFI CPER driver
(Dave Jiang)
- Address multiple assorted issues in the ACPI extlog driver (Dave
Jiang)
- Address two issues related to CXL in the ACPI APEI GHES driver
(Dave Jiang)
- Read only validated fields in cper_mem_err_pack() (Dave Jiang)
- Validate memory error section length before payload access, prevent
writes past array bounds from occurring and sanitize software
metadata in the ACPI APEI GHES driver (Dave Jiang)
- Make cxl_cper_handle_prot_err() static (Dave Jiang)
- Add IOVT IOMMU support to ACPICA (Bibo Mao)
- Fix PCC OperationRegion command offsets in ACPICA (Sudeep Holla)
- Fix memory leak in acpi_ds_create_field() related to the handling
of internal_pcc_buffer allocations (Breno Leitao)
- Fix memory leak due to leftover devm_kcalloc() argument in the ACPI
fan driver (Rafael Wysocki)
- Fix backlight unregistration ordering in the ACPI video bus device
driver (Rafael Wysocki)
- Update the thermal core to allow the registration of thermal class
cooling devices under specific parents and convert the ACPI fan,
ACPI processor, and ACPI video bus device drivers to do so (Rafael
Wysocki)
- Adjust the ACPI thermal zone driver to use thermal class cooling
device parent information for binding cooling devices to trip
points in thermal zones (Rafael Wysocki)
- Use cooling device data that is a better match for a given driver
instead of a struct acpi_device pointer that had to be used for
this purpose previously in the ACPI fan and processor drivers
(Rafael Wysocki)
- Fix acpi_thermal_guess_offset() in the ACPI thermal zone driver for
thermal zone devices with a 273.0°K offset (Hans de Goede)
- Define a free for ACPI objects allocated by ACPICA helpers and use
it to simplify AML error handling in the ACPI fan driver (Rafael
Wysocki)
- Switch over the users of acpi_get_first_physical_node(), that was
inherently racy and therefore not really safe to use, to use its
replacement acpi_bus_get_primary_device(), and eliminate the former
(Rafael Wysocki)
- Add !CONFIG_ACPI stubs for acpi_find_child_device() and
acpi_device_uid() (Mario Limonciello and Robin Murphy)
- Fix bogus cycle count values on systems without _BIX in the ACPI
battery driver (Armin Wolf)
- Fix NULL pointer dereference on allocation failure and report
relative state of charge as CAPACITY in the ACPI SBS driver (Itay
Shem-tov and Guangshuo Li)
- Add lid_init_state quirk for Razer Blade Stealth 13 (Early 2020)
RZ09-0310 to the ACPI button driver (Ian Gallagher)
- Add new quirks to force the native backlight on Dell OptiPlex AIO
7410 35W and Acer Nitro AN515-58 in the ACPI video bus device
driver (Chitransh Mandhaniya and Dirga Yuza)
- Fix the shared memory signature handling in the ACPI PCC address
space handler, free the PCC mailbox channel on operation region
deactivation, and avoid unnecessary repeated computations of the
PCC operation region command timeout (Sudeep Holla)
- Fix a log message typo in the ACPI NUMA support code (Hemanth
Selam)
- Zero-initialize capability query result in the ACPI Platform
Firmware Runtime Update and Telemetry driver to avoid disclosure of
kernel stack data to user space (Karl Mehltretter)
- Replace the remaining built-in/module check for CONFIG_ACPI_WMI in
a header file with IS_ENABLED() macro (Lalit Shankar Chowdhury)
- Retry probing battery docks after hotplug in the ACPI docking
station driver to avoid missing ACPI add notifications (Vibhor
Goel)
- Detach device after resource transition failure in
pnp_device_probe() to avoid blocking later manual PNP configuration
attempts (Myeonghun Pak)"
* tag 'acpi-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (90 commits)
ACPI: PM: Add Acer Aspire A515-53G to dmi_leave_unused_power_resources_on[]
ACPI: video: force native backlight on Dell OptiPlex AIO 7410 35W
ACPI: PM: sleep: Drop unused sleep_no_lps0 define
ACPI: PM: Add unused power resource quirk for Casper Excalibur G900
ACPI: dock: Retry probing battery docks after hotplug
ACPI: PCI: pci_link: clear driver_data before free
ACPI: APEI: accumulate the queued flag across error sections
ACPICA: actbl2.h: Add bit constants of the Flags field in the IOVT IOMMU structure
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()
PCI/AER: Map a raw AER Capability image field by field
ACPI: NUMA: fix typo in log message
ACPI: Add stub for acpi_find_child_device()
driver core/ACPI: Introduce companion_bus_register()
ACPI: PCC: Cache OpRegion command timeout
ACPI: PCC: Free channel on OpRegion deactivation
ACPI: PCC: Preserve shared memory signature in OpRegion handler
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux
Pull Kbuild / Kconfig updates from Nathan Chancellor:
"Kbuild:
- Suppress compiler flags in debug info for external module builds
- Use '-fmacro-prefix-map' in more places in the build
- Merge initial set of changes from Lorenzo's speed up series, along
with some fixes found through testing:
- Avoid allocating .modinfo in vmlinux
- Speed up kallsyms by indexing symbols by token and outputting
binary data to disk directly then including in assembly via
.incbin
- Don't sort $(NM) output when unnecessary
- Only emit relocations on the final vmlinx link
- Reimplement mksysmap in C
- Move many cc-option and ld-option calls into the Kconfig stage to
cache their results
- Use pigz for gzip compression when available
- Move gen_init_cpio and gen_initramfs.sh from usr/ to scripts/
- Add a TOML configuration to scripts/container and update
documentation accordingly
- Add a generic, opt-in mechanism for checking that headers can
compile standalone
- Update machine function splitting argument for LLVM 24 rename in
AutoFDO build
- Miscellaneous minor clean ups, fixes, and hardening, mostly
found/fixed via LLMs
Kconfig:
- Turn recursive ranges into an error
- Fix savedefconfig for defaults that were adjusted for being out of
range and revert a previously applied workaround
- Improvements and hardening around integer and hexadecimal values
- Emit a warning when selecting or implying a choice symbol, which
has no effect
- Emit a warning when KCONFIG_PROBABILITY is malformed
- Introduce def_string / def_int / def_hex to mirror the existing
def_bool / def_tristate to succinctly set a value and type at the
same time.
- Add cc-option-str and ld-option-str macros to act like Kbuild's
cc-option and ld-option, returning the string when the option is
supported, allowing many checks to be moved into Kconfig
- Minor usability improvements to Kconfig tests"
* tag 'kbuild-7.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: (59 commits)
kbuild: AutoFDO: Update split machine function argument for upstream rename
kbuild: Mark the initcall ordering recipe as recursive
kbuild: Mark the gzip recipes as recursive
localmodconfig: Explicitly report boolean configs during integrity check
scripts/make_fit: Ignore schema checks when decomposing DTBs
clang-tools: Import os for broken pipe handling
kconfig: use the value argument in sym_get_near_range_bound()
kconfig: fix infinite loop in conf_choice() when no choice value is visible
kconfig: cleanup stale comment about 'keys' array
kconfig: Improve ergonomics around disabling warnings with cc-option
scripts/Kconfig.toolchain: Drop compiler symbols from dependencies
checkkconfigsymbols.py: Parse Git status output line by line
gen_init_cpio: stop parsing on lines with a missing argument list
.gitignore: drop Module.markers
.gitignore: ignore pacman package signatures
kbuild: add header check facility as a manually run static analyzer
Documentation: dev-tools: refer to user ID rather than id
Documentation: dev-tools: update container.rst with config file
scripts: add TOML config to container tool
kconfig: tests: {old,save}defconfig: Forward dynamic keyword arguments
...
|
|
Merge changes related to ACPI support in device drivers for 7.4:
- Switch over the users of acpi_get_first_physical_node(), that
was inherently racy and therefore not really safe to use, to use
its replacement acpi_bus_get_primary_device(), and eliminate the
former (Rafael Wysocki)
- Add !CONFIG_ACPI stubs for acpi_find_child_device() and
acpi_device_uid() (Mario Limonciello and Robin Murphy)
* 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
|
|
Two bugs were found in the arm64 EFI runtime support that weren't caught
by LKDTM. The existing EFI_RUNTIME_CRASH test instructs the firmware to
write to kernel memory that is mapped read-only, which usually fails as
expected. However, this does not exercise the runtime mapping logic in
the kernel, nor the fault recovery logic when the faulting address is
inside the EFI runtime memory regions itself.
So add two more test cases:
- a write to R/O memory test that uses the firmware's own executable
memory as an output buffer
- a branch to memory that is occupied by the firmware's runtime services
function table, which is usually mapped non-execute.
This depends on the EFI memory attributes table having been exposed by
the firmware and having been taken into account by the runtime mapping
code, so this is used as a prerequisite by the new tests, otherwise it
produces an XFAIL.
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The addresses of the MOK variable table, the confidential computing
secret area and the unaccepted memory table in struct efi are only
initialized to EFI_INVALID_TABLE_ADDR if support for the respective
table is enabled, and are left at 0 otherwise. This is harmless for
the existing users, which are compiled out in that case, but code that
consumes the table addresses in struct efi generically, such as a kexec
loader that passes the configuration tables on to the incoming kernel,
would mistake 0 for a valid table address.
So initialize all of them unconditionally: efi_config_parse_tables()
only assigns them if support for the table is enabled, and so they
remain EFI_INVALID_TABLE_ADDR otherwise.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The physical address of the LINUX_EFI_MEMRESERVE configuration table is
only kept in __initdata, but a kexec loader that runs the incoming
kernel's EFI stub needs it in order to pass the table on, so that the
persistent memory reservations made by this kernel and its predecessors
(e.g., for the GICv3 LPI tables) are carried over.
So move it into struct efi, alongside the addresses of the other EFI
configuration tables that may be passed on in this way.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The LINUX_EFI_MEMRESERVE table is the root of a linked list of memory
reservations that need to persist across kexec, such as the GICv3 LPI
pending and property tables, which cannot be moved once the
redistributors have been enabled. Each kernel adds its own reservations
to the list that it finds via the EFI configuration table, and honours
the ones made by its predecessors.
The EFI stub installs a new, empty table unconditionally, replacing any
existing one. This is fine on a cold boot, but not if the stub is being
executed by a loader that passes on the configuration tables of an
earlier kernel, e.g., a kexec loader that runs the incoming kernel's EFI
stub, as the reservations made by earlier kernels would be lost.
So leave an existing table in place, and only install a new one if none
exists yet.
Cc: <stable@vger.kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@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>
|
|
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.
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.
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.
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>
|
|
The UEFI specification designates x18, the platform register, as "do not
use" on AArch64, so that UEFI code is compatible both with an OS that
assigns a fixed role to x18, and with one that uses it as a temporary
register.
The arm64 EFI stub and the EFI zboot decompressor only avoid x18 if the
kernel is built with shadow call stacks, as that is the only case where
-ffixed-x18 is added to KBUILD_CFLAGS, which the stub inherits.
Otherwise, the compiler is free to use x18 as a temporary register, and
it does so.
So pass -ffixed-x18 unconditionally when building the stub for arm64,
so that the image can be run by loaders that rely on x18 being left
alone, such as a kernel that uses it for its shadow call stack.
Cc: <stable@vger.kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
