https://github.com/torvalds/linux
Revision 63bf28ceb3ebbe76048c3fb2987996ca1ae64f83 authored by Ard Biesheuvel on 04 August 2022, 13:39:48 UTC, committed by Ard Biesheuvel on 22 September 2022, 08:12:51 UTC
When booting the x86 kernel via EFI using the LoadImage/StartImage boot services [as opposed to the deprecated EFI handover protocol], the setup header is taken from the image directly, and given that EFI's LoadImage has no Linux/x86 specific knowledge regarding struct bootparams or struct setup_header, any absolute addresses in the setup header must originate from the file and not from a prior loading stage. Since we cannot generally predict where LoadImage() decides to load an image (*), such absolute addresses must be treated as suspect: even if a prior boot stage intended to make them point somewhere inside the [signed] image, there is no way to validate that, and if they point at an arbitrary location in memory, the setup_data nodes will not be covered by any signatures or TPM measurements either, and could be made to contain an arbitrary sequence of SETUP_xxx nodes, which could interfere quite badly with the early x86 boot sequence. (*) Note that, while LoadImage() does take a buffer/size tuple in addition to a device path, which can be used to provide the image contents directly, it will re-allocate such images, as the memory footprint of an image is generally larger than the PE/COFF file representation. Cc: <stable@vger.kernel.org> # v5.10+ Link: https://lore.kernel.org/all/20220904165321.1140894-1-Jason@zx2c4.com/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
1 parent 7da5b13
Tip revision: 63bf28ceb3ebbe76048c3fb2987996ca1ae64f83 authored by Ard Biesheuvel on 04 August 2022, 13:39:48 UTC
efi: x86: Wipe setup_data on pure EFI boot
efi: x86: Wipe setup_data on pure EFI boot
Tip revision: 63bf28c
Kconfig.kfence
# SPDX-License-Identifier: GPL-2.0-only
config HAVE_ARCH_KFENCE
bool
menuconfig KFENCE
bool "KFENCE: low-overhead sampling-based memory safety error detector"
depends on HAVE_ARCH_KFENCE && (SLAB || SLUB)
select STACKTRACE
select IRQ_WORK
help
KFENCE is a low-overhead sampling-based detector of heap out-of-bounds
access, use-after-free, and invalid-free errors. KFENCE is designed
to have negligible cost to permit enabling it in production
environments.
See <file:Documentation/dev-tools/kfence.rst> for more details.
Note that, KFENCE is not a substitute for explicit testing with tools
such as KASAN. KFENCE can detect a subset of bugs that KASAN can
detect, albeit at very different performance profiles. If you can
afford to use KASAN, continue using KASAN, for example in test
environments. If your kernel targets production use, and cannot
enable KASAN due to its cost, consider using KFENCE.
if KFENCE
config KFENCE_SAMPLE_INTERVAL
int "Default sample interval in milliseconds"
default 100
help
The KFENCE sample interval determines the frequency with which heap
allocations will be guarded by KFENCE. May be overridden via boot
parameter "kfence.sample_interval".
Set this to 0 to disable KFENCE by default, in which case only
setting "kfence.sample_interval" to a non-zero value enables KFENCE.
config KFENCE_NUM_OBJECTS
int "Number of guarded objects available"
range 1 65535
default 255
help
The number of guarded objects available. For each KFENCE object, 2
pages are required; with one containing the object and two adjacent
ones used as guard pages.
config KFENCE_DEFERRABLE
bool "Use a deferrable timer to trigger allocations"
help
Use a deferrable timer to trigger allocations. This avoids forcing
CPU wake-ups if the system is idle, at the risk of a less predictable
sample interval.
Warning: The KUnit test suite fails with this option enabled - due to
the unpredictability of the sample interval!
Say N if you are unsure.
config KFENCE_STATIC_KEYS
bool "Use static keys to set up allocations" if EXPERT
depends on JUMP_LABEL
help
Use static keys (static branches) to set up KFENCE allocations. This
option is only recommended when using very large sample intervals, or
performance has carefully been evaluated with this option.
Using static keys comes with trade-offs that need to be carefully
evaluated given target workloads and system architectures. Notably,
enabling and disabling static keys invoke IPI broadcasts, the latency
and impact of which is much harder to predict than a dynamic branch.
Say N if you are unsure.
config KFENCE_STRESS_TEST_FAULTS
int "Stress testing of fault handling and error reporting" if EXPERT
default 0
help
The inverse probability with which to randomly protect KFENCE object
pages, resulting in spurious use-after-frees. The main purpose of
this option is to stress test KFENCE with concurrent error reports
and allocations/frees. A value of 0 disables stress testing logic.
Only for KFENCE testing; set to 0 if you are not a KFENCE developer.
config KFENCE_KUNIT_TEST
tristate "KFENCE integration test suite" if !KUNIT_ALL_TESTS
default KUNIT_ALL_TESTS
depends on TRACEPOINTS && KUNIT
help
Test suite for KFENCE, testing various error detection scenarios with
various allocation types, and checking that reports are correctly
output to console.
Say Y here if you want the test to be built into the kernel and run
during boot; say M if you want the test to build as a module; say N
if you are unsure.
endif # KFENCE
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...