mirror of
https://github.com/torvalds/linux.git
synced 2025-12-07 20:06:24 +00:00
913e65a2fe
crash_exclude_mem_range seems to be a simple function but there have been multiple attempts to fix it, - commita2e9a95d21("kexec: Improve & fix crash_exclude_mem_range() to handle overlapping ranges") - commit6dff315972("crash_core: fix and simplify the logic of crash_exclude_mem_range()") So add a set of unit tests to verify the correctness of current implementation. Shall we change the function in the future, the unit tests can also help prevent any regression. For example, we may make the function smarter by allocating extra crash_mem range on demand thus there is no need for the caller to foresee any memory range split or address -ENOMEM failure. The testing strategy is to verify the correctness of base case. The base case is there is one to-be-excluded range A and one existing range B. Then we can exhaust all possibilities of the position of A regarding B. For example, here are two combinations, Case: A is completely inside B (causes split) Original: [----B----] Exclude: {--A--} Result: [B1] .. [B2] Case: A overlaps B's left part Original: [----B----] Exclude: {---A---} Result: [..B..] In theory we can prove the correctness by induction, - Base case: crash_exclude_mem_range is correct in the case where n=1 (n is the number of existing ranges). - Inductive step: If crash_exclude_mem_range is correct for n=k existing ranges, then the it's also correct for n=k+1 ranges. But for the sake of simplicity, simply use unit tests to cover the base case together with two regression tests. Note most of the exclude_single_range_test() code is generated by Google Gemini with some small tweaks. The function specification, function body and the exhausting test strategy are presented as prompts. [akpm@linux-foundation.org: export crash_exclude_mem_range() to modules, for kernel/crash_core_test.c] Link: https://lkml.kernel.org/r/20250904093855.1180154-2-coxu@redhat.com Signed-off-by: Coiby Xu <coxu@redhat.com> Assisted-by: Google Gemini Cc: Baoquan He <bhe@redhat.com> Cc: Borislav Betkov <bp@alien8.de> Cc: Dave Young <dyoung@redhat.com> Cc: fuqiang wang <fuqiang.wang@easystack.cn> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleinxer <tglx@linutronix.de> Cc: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
198 lines
6.5 KiB
Plaintext
198 lines
6.5 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
menu "Kexec and crash features"
|
|
|
|
config CRASH_RESERVE
|
|
bool
|
|
|
|
config VMCORE_INFO
|
|
bool
|
|
|
|
config KEXEC_CORE
|
|
bool
|
|
|
|
config KEXEC_ELF
|
|
bool
|
|
|
|
config HAVE_IMA_KEXEC
|
|
bool
|
|
|
|
config KEXEC
|
|
bool "Enable kexec system call"
|
|
depends on ARCH_SUPPORTS_KEXEC
|
|
select KEXEC_CORE
|
|
help
|
|
kexec is a system call that implements the ability to shutdown your
|
|
current kernel, and to start another kernel. It is like a reboot
|
|
but it is independent of the system firmware. And like a reboot
|
|
you can start any kernel with it, not just Linux.
|
|
|
|
The name comes from the similarity to the exec system call.
|
|
|
|
It is an ongoing process to be certain the hardware in a machine
|
|
is properly shutdown, so do not be surprised if this code does not
|
|
initially work for you. As of this writing the exact hardware
|
|
interface is strongly in flux, so no good recommendation can be
|
|
made.
|
|
|
|
config KEXEC_FILE
|
|
bool "Enable kexec file based system call"
|
|
depends on ARCH_SUPPORTS_KEXEC_FILE
|
|
select CRYPTO_LIB_SHA256
|
|
select KEXEC_CORE
|
|
help
|
|
This is new version of kexec system call. This system call is
|
|
file based and takes file descriptors as system call argument
|
|
for kernel and initramfs as opposed to list of segments as
|
|
accepted by kexec system call.
|
|
|
|
config KEXEC_SIG
|
|
bool "Verify kernel signature during kexec_file_load() syscall"
|
|
depends on ARCH_SUPPORTS_KEXEC_SIG
|
|
depends on KEXEC_FILE
|
|
help
|
|
This option makes the kexec_file_load() syscall check for a valid
|
|
signature of the kernel image. The image can still be loaded without
|
|
a valid signature unless you also enable KEXEC_SIG_FORCE, though if
|
|
there's a signature that we can check, then it must be valid.
|
|
|
|
In addition to this option, you need to enable signature
|
|
verification for the corresponding kernel image type being
|
|
loaded in order for this to work.
|
|
|
|
config KEXEC_SIG_FORCE
|
|
bool "Require a valid signature in kexec_file_load() syscall"
|
|
depends on ARCH_SUPPORTS_KEXEC_SIG_FORCE
|
|
depends on KEXEC_SIG
|
|
help
|
|
This option makes kernel signature verification mandatory for
|
|
the kexec_file_load() syscall.
|
|
|
|
config KEXEC_IMAGE_VERIFY_SIG
|
|
bool "Enable Image signature verification support (ARM)"
|
|
default ARCH_DEFAULT_KEXEC_IMAGE_VERIFY_SIG
|
|
depends on ARCH_SUPPORTS_KEXEC_IMAGE_VERIFY_SIG
|
|
depends on KEXEC_SIG
|
|
depends on EFI && SIGNED_PE_FILE_VERIFICATION
|
|
help
|
|
Enable Image signature verification support.
|
|
|
|
config KEXEC_BZIMAGE_VERIFY_SIG
|
|
bool "Enable bzImage signature verification support"
|
|
depends on ARCH_SUPPORTS_KEXEC_BZIMAGE_VERIFY_SIG
|
|
depends on KEXEC_SIG
|
|
depends on SIGNED_PE_FILE_VERIFICATION
|
|
select SYSTEM_TRUSTED_KEYRING
|
|
help
|
|
Enable bzImage signature verification support.
|
|
|
|
config KEXEC_JUMP
|
|
bool "kexec jump"
|
|
depends on ARCH_SUPPORTS_KEXEC_JUMP
|
|
depends on KEXEC && HIBERNATION
|
|
help
|
|
Jump between original kernel and kexeced kernel and invoke
|
|
code in physical address mode via KEXEC
|
|
|
|
config KEXEC_HANDOVER
|
|
bool "kexec handover"
|
|
depends on ARCH_SUPPORTS_KEXEC_HANDOVER && ARCH_SUPPORTS_KEXEC_FILE
|
|
depends on !DEFERRED_STRUCT_PAGE_INIT
|
|
select MEMBLOCK_KHO_SCRATCH
|
|
select KEXEC_FILE
|
|
select DEBUG_FS
|
|
select LIBFDT
|
|
select CMA
|
|
help
|
|
Allow kexec to hand over state across kernels by generating and
|
|
passing additional metadata to the target kernel. This is useful
|
|
to keep data or state alive across the kexec. For this to work,
|
|
both source and target kernels need to have this option enabled.
|
|
|
|
config CRASH_DUMP
|
|
bool "kernel crash dumps"
|
|
default ARCH_DEFAULT_CRASH_DUMP
|
|
depends on ARCH_SUPPORTS_CRASH_DUMP
|
|
depends on KEXEC_CORE
|
|
select VMCORE_INFO
|
|
select CRASH_RESERVE
|
|
help
|
|
Generate crash dump after being started by kexec.
|
|
This should be normally only set in special crash dump kernels
|
|
which are loaded in the main kernel with kexec-tools into
|
|
a specially reserved region and then later executed after
|
|
a crash by kdump/kexec. The crash dump kernel must be compiled
|
|
to a memory address not used by the main kernel or BIOS using
|
|
PHYSICAL_START, or it must be built as a relocatable image
|
|
(CONFIG_RELOCATABLE=y).
|
|
For more details see Documentation/admin-guide/kdump/kdump.rst
|
|
|
|
For s390, this option also enables zfcpdump.
|
|
See also <file:Documentation/arch/s390/zfcpdump.rst>
|
|
|
|
config CRASH_DM_CRYPT
|
|
bool "Support saving crash dump to dm-crypt encrypted volume"
|
|
depends on KEXEC_FILE
|
|
depends on CRASH_DUMP
|
|
depends on DM_CRYPT
|
|
depends on KEYS
|
|
help
|
|
With this option enabled, user space can intereact with
|
|
/sys/kernel/config/crash_dm_crypt_keys to make the dm crypt keys
|
|
persistent for the dump-capture kernel.
|
|
|
|
config CRASH_DM_CRYPT_CONFIGS
|
|
def_tristate CRASH_DM_CRYPT
|
|
select CONFIGFS_FS
|
|
help
|
|
CRASH_DM_CRYPT cannot directly select CONFIGFS_FS, because that
|
|
is required to be built-in.
|
|
|
|
config CRASH_DUMP_KUNIT_TEST
|
|
tristate "Unit Tests for kernel crash dumps" if !KUNIT_ALL_TESTS
|
|
depends on CRASH_DUMP && KUNIT
|
|
default KUNIT_ALL_TESTS
|
|
help
|
|
This option builds KUnit unit tests for kernel crash dumps. The unit
|
|
tests will be used to verify the correctness of covered functions and
|
|
also prevent any regression.
|
|
|
|
If unsure, say N.
|
|
|
|
config CRASH_HOTPLUG
|
|
bool "Update the crash elfcorehdr on system configuration changes"
|
|
default y
|
|
depends on CRASH_DUMP && (HOTPLUG_CPU || MEMORY_HOTPLUG)
|
|
depends on ARCH_SUPPORTS_CRASH_HOTPLUG
|
|
help
|
|
Enable direct update to the crash elfcorehdr (which contains
|
|
the list of CPUs and memory regions to be dumped upon a crash)
|
|
in response to hot plug/unplug or online/offline of CPUs or
|
|
memory. This is a much more advanced approach than userspace
|
|
attempting that.
|
|
|
|
If unsure, say Y.
|
|
|
|
config CRASH_MAX_MEMORY_RANGES
|
|
int "Specify the maximum number of memory regions for the elfcorehdr"
|
|
default 8192
|
|
depends on CRASH_HOTPLUG
|
|
help
|
|
For the kexec_file_load() syscall path, specify the maximum number of
|
|
memory regions that the elfcorehdr buffer/segment can accommodate.
|
|
These regions are obtained via walk_system_ram_res(); eg. the
|
|
'System RAM' entries in /proc/iomem.
|
|
This value is combined with NR_CPUS_DEFAULT and multiplied by
|
|
sizeof(Elf64_Phdr) to determine the final elfcorehdr memory buffer/
|
|
segment size.
|
|
The value 8192, for example, covers a (sparsely populated) 1TiB system
|
|
consisting of 128MiB memblocks, while resulting in an elfcorehdr
|
|
memory buffer/segment size under 1MiB. This represents a sane choice
|
|
to accommodate both baremetal and virtual machine configurations.
|
|
|
|
For the kexec_load() syscall path, CRASH_MAX_MEMORY_RANGES is part of
|
|
the computation behind the value provided through the
|
|
/sys/kernel/crash_elfcorehdr_size attribute.
|
|
|
|
endmenu
|