License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2005-06-25 21:57:52 +00:00
|
|
|
#ifndef LINUX_KEXEC_H
|
|
|
|
|
#define LINUX_KEXEC_H
|
|
|
|
|
|
2015-02-17 21:45:56 +00:00
|
|
|
#define IND_DESTINATION_BIT 0
|
|
|
|
|
#define IND_INDIRECTION_BIT 1
|
|
|
|
|
#define IND_DONE_BIT 2
|
|
|
|
|
#define IND_SOURCE_BIT 3
|
|
|
|
|
|
|
|
|
|
#define IND_DESTINATION (1 << IND_DESTINATION_BIT)
|
|
|
|
|
#define IND_INDIRECTION (1 << IND_INDIRECTION_BIT)
|
|
|
|
|
#define IND_DONE (1 << IND_DONE_BIT)
|
|
|
|
|
#define IND_SOURCE (1 << IND_SOURCE_BIT)
|
2015-02-17 21:45:58 +00:00
|
|
|
#define IND_FLAGS (IND_DESTINATION | IND_INDIRECTION | IND_DONE | IND_SOURCE)
|
2015-02-17 21:45:56 +00:00
|
|
|
|
|
|
|
|
#if !defined(__ASSEMBLY__)
|
|
|
|
|
|
2024-01-24 05:12:42 +00:00
|
|
|
#include <linux/vmcore_info.h>
|
kexec: split crashkernel reservation code out from crash_core.c
Patch series "Split crash out from kexec and clean up related config
items", v3.
Motivation:
=============
Previously, LKP reported a building error. When investigating, it can't
be resolved reasonablly with the present messy kdump config items.
https://lore.kernel.org/oe-kbuild-all/202312182200.Ka7MzifQ-lkp@intel.com/
The kdump (crash dumping) related config items could causes confusions:
Firstly,
CRASH_CORE enables codes including
- crashkernel reservation;
- elfcorehdr updating;
- vmcoreinfo exporting;
- crash hotplug handling;
Now fadump of powerpc, kcore dynamic debugging and kdump all selects
CRASH_CORE, while fadump
- fadump needs crashkernel parsing, vmcoreinfo exporting, and accessing
global variable 'elfcorehdr_addr';
- kcore only needs vmcoreinfo exporting;
- kdump needs all of the current kernel/crash_core.c.
So only enabling PROC_CORE or FA_DUMP will enable CRASH_CORE, this
mislead people that we enable crash dumping, actual it's not.
Secondly,
It's not reasonable to allow KEXEC_CORE select CRASH_CORE.
Because KEXEC_CORE enables codes which allocate control pages, copy
kexec/kdump segments, and prepare for switching. These codes are
shared by both kexec reboot and kdump. We could want kexec reboot,
but disable kdump. In that case, CRASH_CORE should not be selected.
--------------------
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_KEXEC=y
CONFIG_KEXEC_FILE=y
---------------------
Thirdly,
It's not reasonable to allow CRASH_DUMP select KEXEC_CORE.
That could make KEXEC_CORE, CRASH_DUMP are enabled independently from
KEXEC or KEXEC_FILE. However, w/o KEXEC or KEXEC_FILE, the KEXEC_CORE
code built in doesn't make any sense because no kernel loading or
switching will happen to utilize the KEXEC_CORE code.
---------------------
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_CRASH_DUMP=y
---------------------
In this case, what is worse, on arch sh and arm, KEXEC relies on MMU,
while CRASH_DUMP can still be enabled when !MMU, then compiling error is
seen as the lkp test robot reported in above link.
------arch/sh/Kconfig------
config ARCH_SUPPORTS_KEXEC
def_bool MMU
config ARCH_SUPPORTS_CRASH_DUMP
def_bool BROKEN_ON_SMP
---------------------------
Changes:
===========
1, split out crash_reserve.c from crash_core.c;
2, split out vmcore_infoc. from crash_core.c;
3, move crash related codes in kexec_core.c into crash_core.c;
4, remove dependency of FA_DUMP on CRASH_DUMP;
5, clean up kdump related config items;
6, wrap up crash codes in crash related ifdefs on all 8 arch-es
which support crash dumping, except of ppc;
Achievement:
===========
With above changes, I can rearrange the config item logic as below (the right
item depends on or is selected by the left item):
PROC_KCORE -----------> VMCORE_INFO
|----------> VMCORE_INFO
FA_DUMP----|
|----------> CRASH_RESERVE
---->VMCORE_INFO
/
|---->CRASH_RESERVE
KEXEC --| /|
|--> KEXEC_CORE--> CRASH_DUMP-->/-|---->PROC_VMCORE
KEXEC_FILE --| \ |
\---->CRASH_HOTPLUG
KEXEC --|
|--> KEXEC_CORE (for kexec reboot only)
KEXEC_FILE --|
Test
========
On all 8 architectures, including x86_64, arm64, s390x, sh, arm, mips,
riscv, loongarch, I did below three cases of config item setting and
building all passed. Take configs on x86_64 as exampmle here:
(1) Both CONFIG_KEXEC and KEXEC_FILE is unset, then all kexec/kdump
items are unset automatically:
# Kexec and crash features
# CONFIG_KEXEC is not set
# CONFIG_KEXEC_FILE is not set
# end of Kexec and crash features
(2) set CONFIG_KEXEC_FILE and 'make olddefconfig':
---------------
# Kexec and crash features
CONFIG_CRASH_RESERVE=y
CONFIG_VMCORE_INFO=y
CONFIG_KEXEC_CORE=y
CONFIG_KEXEC_FILE=y
CONFIG_CRASH_DUMP=y
CONFIG_CRASH_HOTPLUG=y
CONFIG_CRASH_MAX_MEMORY_RANGES=8192
# end of Kexec and crash features
---------------
(3) unset CONFIG_CRASH_DUMP in case 2 and execute 'make olddefconfig':
------------------------
# Kexec and crash features
CONFIG_KEXEC_CORE=y
CONFIG_KEXEC_FILE=y
# end of Kexec and crash features
------------------------
Note:
For ppc, it needs investigation to make clear how to split out crash
code in arch folder. Hope Hari and Pingfan can help have a look, see if
it's doable. Now, I make it either have both kexec and crash enabled, or
disable both of them altogether.
This patch (of 14):
Both kdump and fa_dump of ppc rely on crashkernel reservation. Move the
relevant codes into separate files: crash_reserve.c,
include/linux/crash_reserve.h.
And also add config item CRASH_RESERVE to control its enabling of the
codes. And update config items which has relationship with crashkernel
reservation.
And also change ifdeffery from CONFIG_CRASH_CORE to CONFIG_CRASH_RESERVE
when those scopes are only crashkernel reservation related.
And also rename arch/XXX/include/asm/{crash_core.h => crash_reserve.h} on
arm64, x86 and risc-v because those architectures' crash_core.h is only
related to crashkernel reservation.
[akpm@linux-foundation.org: s/CRASH_RESEERVE/CRASH_RESERVE/, per Klara Modin]
Link: https://lkml.kernel.org/r/20240124051254.67105-1-bhe@redhat.com
Link: https://lkml.kernel.org/r/20240124051254.67105-2-bhe@redhat.com
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Pingfan Liu <piliu@redhat.com>
Cc: Klara Modin <klarasmodin@gmail.com>
Cc: Michael Kelley <mhklinux@outlook.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-24 05:12:41 +00:00
|
|
|
#include <linux/crash_reserve.h>
|
2016-08-02 21:06:04 +00:00
|
|
|
#include <asm/io.h>
|
2022-09-29 04:29:35 +00:00
|
|
|
#include <linux/range.h>
|
2016-08-02 21:06:04 +00:00
|
|
|
|
2012-10-13 09:46:48 +00:00
|
|
|
#include <uapi/linux/kexec.h>
|
2022-07-14 13:40:25 +00:00
|
|
|
#include <linux/verification.h>
|
2012-05-31 23:26:27 +00:00
|
|
|
|
kexec: make crashk_res, crashk_low_res and crash_notes symbols always visible
Patch series "kexec: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef", v2.
Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE" by
a check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code and
increase compile coverage.
I only modified x86, arm, arm64 and riscv, other architectures such as
sh, powerpc and s390 are better to be kept kexec code as-is so they are
not touched.
This patch (of 5):
Make the forward declarations of crashk_res, crashk_low_res and
crash_notes always visible. Code referring to these symbols can then just
check for IS_ENABLED(CONFIG_KEXEC_CORE), instead of requiring conditional
compilation using an #ifdef, thus preparing to increase compile coverage
and simplify the code.
Link: https://lkml.kernel.org/r/20211206160514.2000-1-jszhang@kernel.org
Link: https://lkml.kernel.org/r/20211206160514.2000-2-jszhang@kernel.org
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-03-23 23:06:33 +00:00
|
|
|
extern note_buf_t __percpu *crash_notes;
|
|
|
|
|
|
kexec_file: allow to place kexec_buf randomly
Patch series "Support kdump with LUKS encryption by reusing LUKS volume
keys", v9.
LUKS is the standard for Linux disk encryption, widely adopted by users,
and in some cases, such as Confidential VMs, it is a requirement. With
kdump enabled, when the first kernel crashes, the system can boot into the
kdump/crash kernel to dump the memory image (i.e., /proc/vmcore) to a
specified target. However, there are two challenges when dumping vmcore
to a LUKS-encrypted device:
- Kdump kernel may not be able to decrypt the LUKS partition. For some
machines, a system administrator may not have a chance to enter the
password to decrypt the device in kdump initramfs after the 1st kernel
crashes; For cloud confidential VMs, depending on the policy the
kdump kernel may not be able to unseal the keys with TPM and the
console virtual keyboard is untrusted.
- LUKS2 by default use the memory-hard Argon2 key derivation function
which is quite memory-consuming compared to the limited memory reserved
for kdump. Take Fedora example, by default, only 256M is reserved for
systems having memory between 4G-64G. With LUKS enabled, ~1300M needs
to be reserved for kdump. Note if the memory reserved for kdump can't
be used by 1st kernel i.e. an user sees ~1300M memory missing in the
1st kernel.
Besides users (at least for Fedora) usually expect kdump to work out of
the box i.e. no manual password input or custom crashkernel value is
needed. And it doesn't make sense to derivate the keys again in kdump
kernel which seems to be redundant work.
This patchset addresses the above issues by making the LUKS volume keys
persistent for kdump kernel with the help of cryptsetup's new APIs
(--link-vk-to-keyring/--volume-key-keyring). Here is the life cycle of
the kdump copies of LUKS volume keys,
1. After the 1st kernel loads the initramfs during boot, systemd
use an user-input passphrase to de-crypt the LUKS volume keys
or TPM-sealed key and then save the volume keys to specified keyring
(using the --link-vk-to-keyring API) and the key will expire within
specified time.
2. A user space tool (kdump initramfs loader like kdump-utils) create
key items inside /sys/kernel/config/crash_dm_crypt_keys to inform
the 1st kernel which keys are needed.
3. When the kdump initramfs is loaded by the kexec_file_load
syscall, the 1st kernel will iterate created key items, save the
keys to kdump reserved memory.
4. When the 1st kernel crashes and the kdump initramfs is booted, the
kdump initramfs asks the kdump kernel to create a user key using the
key stored in kdump reserved memory by writing yes to
/sys/kernel/crash_dm_crypt_keys/restore. Then the LUKS encrypted
device is unlocked with libcryptsetup's --volume-key-keyring API.
5. The system gets rebooted to the 1st kernel after dumping vmcore to
the LUKS encrypted device is finished
After libcryptsetup saving the LUKS volume keys to specified keyring,
whoever takes this should be responsible for the safety of these copies of
keys. The keys will be saved in the memory area exclusively reserved for
kdump where even the 1st kernel has no direct access. And further more,
two additional protections are added,
- save the copy randomly in kdump reserved memory as suggested by Jan
- clear the _PAGE_PRESENT flag of the page that stores the copy as
suggested by Pingfan
This patchset only supports x86. There will be patches to support other
architectures once this patch set gets merged.
This patch (of 9):
Currently, kexec_buf is placed in order which means for the same machine,
the info in the kexec_buf is always located at the same position each time
the machine is booted. This may cause a risk for sensitive information
like LUKS volume key. Now struct kexec_buf has a new field random which
indicates it's supposed to be placed in a random position.
Note this feature is enabled only when CONFIG_CRASH_DUMP is enabled. So
it only takes effect for kdump and won't impact kexec reboot.
Link: https://lkml.kernel.org/r/20250502011246.99238-1-coxu@redhat.com
Link: https://lkml.kernel.org/r/20250502011246.99238-2-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Jan Pazdziora <jpazdziora@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-02 01:12:35 +00:00
|
|
|
#ifdef CONFIG_CRASH_DUMP
|
|
|
|
|
#include <linux/prandom.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-09-09 22:38:55 +00:00
|
|
|
#ifdef CONFIG_KEXEC_CORE
|
2005-06-25 21:57:52 +00:00
|
|
|
#include <linux/list.h>
|
|
|
|
|
#include <linux/compat.h>
|
2006-02-10 09:51:05 +00:00
|
|
|
#include <linux/ioport.h>
|
2014-08-08 21:26:04 +00:00
|
|
|
#include <linux/module.h>
|
crash: add generic infrastructure for crash hotplug support
To support crash hotplug, a mechanism is needed to update the crash
elfcorehdr upon CPU or memory changes (eg. hot un/plug or off/ onlining).
The crash elfcorehdr describes the CPUs and memory to be written into the
vmcore.
To track CPU changes, callbacks are registered with the cpuhp mechanism
via cpuhp_setup_state_nocalls(CPUHP_BP_PREPARE_DYN). The crash hotplug
elfcorehdr update has no explicit ordering requirement (relative to other
cpuhp states), so meets the criteria for utilizing CPUHP_BP_PREPARE_DYN.
CPUHP_BP_PREPARE_DYN is a dynamic state and avoids the need to introduce a
new state for crash hotplug. Also, CPUHP_BP_PREPARE_DYN is the last state
in the PREPARE group, just prior to the STARTING group, which is very
close to the CPU starting up in a plug/online situation, or stopping in a
unplug/ offline situation. This minimizes the window of time during an
actual plug/online or unplug/offline situation in which the elfcorehdr
would be inaccurate. Note that for a CPU being unplugged or offlined, the
CPU will still be present in the list of CPUs generated by
crash_prepare_elf64_headers(). However, there is no need to explicitly
omit the CPU, see justification in 'crash: change
crash_prepare_elf64_headers() to for_each_possible_cpu()'.
To track memory changes, a notifier is registered to capture the memblock
MEM_ONLINE and MEM_OFFLINE events via register_memory_notifier().
The CPU callbacks and memory notifiers invoke crash_handle_hotplug_event()
which performs needed tasks and then dispatches the event to the
architecture specific arch_crash_handle_hotplug_event() to update the
elfcorehdr with the current state of CPUs and memory. During the process,
the kexec_lock is held.
Link: https://lkml.kernel.org/r/20230814214446.6659-3-eric.devolder@oracle.com
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Akhil Raj <lf32.dev@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Weißschuh <linux@weissschuh.net>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-14 21:44:40 +00:00
|
|
|
#include <linux/highmem.h>
|
2005-06-25 21:57:52 +00:00
|
|
|
#include <asm/kexec.h>
|
2024-01-24 05:12:44 +00:00
|
|
|
#include <linux/crash_core.h>
|
2005-06-25 21:57:52 +00:00
|
|
|
|
|
|
|
|
/* Verify architecture specific macros are defined */
|
|
|
|
|
|
|
|
|
|
#ifndef KEXEC_SOURCE_MEMORY_LIMIT
|
|
|
|
|
#error KEXEC_SOURCE_MEMORY_LIMIT not defined
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef KEXEC_DESTINATION_MEMORY_LIMIT
|
|
|
|
|
#error KEXEC_DESTINATION_MEMORY_LIMIT not defined
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef KEXEC_CONTROL_MEMORY_LIMIT
|
|
|
|
|
#error KEXEC_CONTROL_MEMORY_LIMIT not defined
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-04-16 12:47:33 +00:00
|
|
|
#ifndef KEXEC_CONTROL_MEMORY_GFP
|
2016-08-02 21:05:54 +00:00
|
|
|
#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
|
2015-04-16 12:47:33 +00:00
|
|
|
#endif
|
|
|
|
|
|
2008-08-15 07:40:22 +00:00
|
|
|
#ifndef KEXEC_CONTROL_PAGE_SIZE
|
|
|
|
|
#error KEXEC_CONTROL_PAGE_SIZE not defined
|
2005-06-25 21:57:52 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef KEXEC_ARCH
|
|
|
|
|
#error KEXEC_ARCH not defined
|
|
|
|
|
#endif
|
|
|
|
|
|
2011-10-30 14:16:36 +00:00
|
|
|
#ifndef KEXEC_CRASH_CONTROL_MEMORY_LIMIT
|
|
|
|
|
#define KEXEC_CRASH_CONTROL_MEMORY_LIMIT KEXEC_CONTROL_MEMORY_LIMIT
|
|
|
|
|
#endif
|
|
|
|
|
|
2011-10-30 14:16:43 +00:00
|
|
|
#ifndef KEXEC_CRASH_MEM_ALIGN
|
|
|
|
|
#define KEXEC_CRASH_MEM_ALIGN PAGE_SIZE
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-06-25 21:57:52 +00:00
|
|
|
/*
|
|
|
|
|
* This structure is used to hold the arguments that are used when loading
|
|
|
|
|
* kernel binaries.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
typedef unsigned long kimage_entry_t;
|
|
|
|
|
|
|
|
|
|
struct kexec_segment {
|
2014-08-08 21:25:52 +00:00
|
|
|
/*
|
|
|
|
|
* This pointer can point to user memory if kexec_load() system
|
|
|
|
|
* call is used or will point to kernel memory if
|
|
|
|
|
* kexec_file_load() system call is used.
|
|
|
|
|
*
|
|
|
|
|
* Use ->buf when expecting to deal with user memory and use ->kbuf
|
|
|
|
|
* when expecting to deal with kernel memory.
|
|
|
|
|
*/
|
|
|
|
|
union {
|
|
|
|
|
void __user *buf;
|
|
|
|
|
void *kbuf;
|
|
|
|
|
};
|
2005-06-25 21:57:52 +00:00
|
|
|
size_t bufsz;
|
2012-05-31 23:26:27 +00:00
|
|
|
unsigned long mem;
|
2005-06-25 21:57:52 +00:00
|
|
|
size_t memsz;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
|
struct compat_kexec_segment {
|
|
|
|
|
compat_uptr_t buf;
|
|
|
|
|
compat_size_t bufsz;
|
|
|
|
|
compat_ulong_t mem; /* User space sees this as a (void *) ... */
|
|
|
|
|
compat_size_t memsz;
|
|
|
|
|
};
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-01-20 23:00:36 +00:00
|
|
|
#ifdef CONFIG_KEXEC_FILE
|
2014-08-08 21:26:04 +00:00
|
|
|
struct purgatory_info {
|
2018-04-13 22:36:17 +00:00
|
|
|
/*
|
|
|
|
|
* Pointer to elf header at the beginning of kexec_purgatory.
|
|
|
|
|
* Note: kexec_purgatory is read only
|
|
|
|
|
*/
|
|
|
|
|
const Elf_Ehdr *ehdr;
|
|
|
|
|
/*
|
|
|
|
|
* Temporary, modifiable buffer for sechdrs used for relocation.
|
|
|
|
|
* This memory can be freed post image load.
|
|
|
|
|
*/
|
2014-08-08 21:26:04 +00:00
|
|
|
Elf_Shdr *sechdrs;
|
|
|
|
|
/*
|
2018-04-13 22:36:17 +00:00
|
|
|
* Temporary, modifiable buffer for stripped purgatory used for
|
|
|
|
|
* relocation. This memory can be freed post image load.
|
2014-08-08 21:26:04 +00:00
|
|
|
*/
|
|
|
|
|
void *purgatory_buf;
|
|
|
|
|
};
|
|
|
|
|
|
2018-04-13 22:36:10 +00:00
|
|
|
struct kimage;
|
|
|
|
|
|
2016-01-20 23:00:36 +00:00
|
|
|
typedef int (kexec_probe_t)(const char *kernel_buf, unsigned long kernel_size);
|
|
|
|
|
typedef void *(kexec_load_t)(struct kimage *image, char *kernel_buf,
|
|
|
|
|
unsigned long kernel_len, char *initrd,
|
|
|
|
|
unsigned long initrd_len, char *cmdline,
|
|
|
|
|
unsigned long cmdline_len);
|
|
|
|
|
typedef int (kexec_cleanup_t)(void *loader_data);
|
|
|
|
|
|
2019-08-20 00:17:44 +00:00
|
|
|
#ifdef CONFIG_KEXEC_SIG
|
2016-01-20 23:00:36 +00:00
|
|
|
typedef int (kexec_verify_sig_t)(const char *kernel_buf,
|
|
|
|
|
unsigned long kernel_len);
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
struct kexec_file_ops {
|
|
|
|
|
kexec_probe_t *probe;
|
|
|
|
|
kexec_load_t *load;
|
|
|
|
|
kexec_cleanup_t *cleanup;
|
2019-08-20 00:17:44 +00:00
|
|
|
#ifdef CONFIG_KEXEC_SIG
|
2016-01-20 23:00:36 +00:00
|
|
|
kexec_verify_sig_t *verify_sig;
|
|
|
|
|
#endif
|
|
|
|
|
};
|
2016-11-29 12:45:47 +00:00
|
|
|
|
2018-04-13 22:35:49 +00:00
|
|
|
extern const struct kexec_file_ops * const kexec_file_loaders[];
|
|
|
|
|
|
|
|
|
|
int kexec_image_probe_default(struct kimage *image, void *buf,
|
|
|
|
|
unsigned long buf_len);
|
2018-11-15 05:52:41 +00:00
|
|
|
int kexec_image_post_load_cleanup_default(struct kimage *image);
|
2018-04-13 22:35:49 +00:00
|
|
|
|
2018-11-15 05:52:42 +00:00
|
|
|
/*
|
|
|
|
|
* If kexec_buf.mem is set to this value, kexec_locate_mem_hole()
|
|
|
|
|
* will try to allocate free memory. Arch may overwrite it.
|
|
|
|
|
*/
|
|
|
|
|
#ifndef KEXEC_BUF_MEM_UNKNOWN
|
|
|
|
|
#define KEXEC_BUF_MEM_UNKNOWN 0
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-11-29 12:45:47 +00:00
|
|
|
/**
|
|
|
|
|
* struct kexec_buf - parameters for finding a place for a buffer in memory
|
|
|
|
|
* @image: kexec image in which memory to search.
|
|
|
|
|
* @buffer: Contents which will be copied to the allocated memory.
|
|
|
|
|
* @bufsz: Size of @buffer.
|
|
|
|
|
* @mem: On return will have address of the buffer in memory.
|
|
|
|
|
* @memsz: Size for the buffer in memory.
|
|
|
|
|
* @buf_align: Minimum alignment needed.
|
|
|
|
|
* @buf_min: The buffer can't be placed below this address.
|
|
|
|
|
* @buf_max: The buffer can't be placed above this address.
|
|
|
|
|
* @top_down: Allocate from top of memory.
|
kexec_file: allow to place kexec_buf randomly
Patch series "Support kdump with LUKS encryption by reusing LUKS volume
keys", v9.
LUKS is the standard for Linux disk encryption, widely adopted by users,
and in some cases, such as Confidential VMs, it is a requirement. With
kdump enabled, when the first kernel crashes, the system can boot into the
kdump/crash kernel to dump the memory image (i.e., /proc/vmcore) to a
specified target. However, there are two challenges when dumping vmcore
to a LUKS-encrypted device:
- Kdump kernel may not be able to decrypt the LUKS partition. For some
machines, a system administrator may not have a chance to enter the
password to decrypt the device in kdump initramfs after the 1st kernel
crashes; For cloud confidential VMs, depending on the policy the
kdump kernel may not be able to unseal the keys with TPM and the
console virtual keyboard is untrusted.
- LUKS2 by default use the memory-hard Argon2 key derivation function
which is quite memory-consuming compared to the limited memory reserved
for kdump. Take Fedora example, by default, only 256M is reserved for
systems having memory between 4G-64G. With LUKS enabled, ~1300M needs
to be reserved for kdump. Note if the memory reserved for kdump can't
be used by 1st kernel i.e. an user sees ~1300M memory missing in the
1st kernel.
Besides users (at least for Fedora) usually expect kdump to work out of
the box i.e. no manual password input or custom crashkernel value is
needed. And it doesn't make sense to derivate the keys again in kdump
kernel which seems to be redundant work.
This patchset addresses the above issues by making the LUKS volume keys
persistent for kdump kernel with the help of cryptsetup's new APIs
(--link-vk-to-keyring/--volume-key-keyring). Here is the life cycle of
the kdump copies of LUKS volume keys,
1. After the 1st kernel loads the initramfs during boot, systemd
use an user-input passphrase to de-crypt the LUKS volume keys
or TPM-sealed key and then save the volume keys to specified keyring
(using the --link-vk-to-keyring API) and the key will expire within
specified time.
2. A user space tool (kdump initramfs loader like kdump-utils) create
key items inside /sys/kernel/config/crash_dm_crypt_keys to inform
the 1st kernel which keys are needed.
3. When the kdump initramfs is loaded by the kexec_file_load
syscall, the 1st kernel will iterate created key items, save the
keys to kdump reserved memory.
4. When the 1st kernel crashes and the kdump initramfs is booted, the
kdump initramfs asks the kdump kernel to create a user key using the
key stored in kdump reserved memory by writing yes to
/sys/kernel/crash_dm_crypt_keys/restore. Then the LUKS encrypted
device is unlocked with libcryptsetup's --volume-key-keyring API.
5. The system gets rebooted to the 1st kernel after dumping vmcore to
the LUKS encrypted device is finished
After libcryptsetup saving the LUKS volume keys to specified keyring,
whoever takes this should be responsible for the safety of these copies of
keys. The keys will be saved in the memory area exclusively reserved for
kdump where even the 1st kernel has no direct access. And further more,
two additional protections are added,
- save the copy randomly in kdump reserved memory as suggested by Jan
- clear the _PAGE_PRESENT flag of the page that stores the copy as
suggested by Pingfan
This patchset only supports x86. There will be patches to support other
architectures once this patch set gets merged.
This patch (of 9):
Currently, kexec_buf is placed in order which means for the same machine,
the info in the kexec_buf is always located at the same position each time
the machine is booted. This may cause a risk for sensitive information
like LUKS volume key. Now struct kexec_buf has a new field random which
indicates it's supposed to be placed in a random position.
Note this feature is enabled only when CONFIG_CRASH_DUMP is enabled. So
it only takes effect for kdump and won't impact kexec reboot.
Link: https://lkml.kernel.org/r/20250502011246.99238-1-coxu@redhat.com
Link: https://lkml.kernel.org/r/20250502011246.99238-2-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Jan Pazdziora <jpazdziora@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-02 01:12:35 +00:00
|
|
|
* @random: Place the buffer at a random position.
|
2016-11-29 12:45:47 +00:00
|
|
|
*/
|
|
|
|
|
struct kexec_buf {
|
|
|
|
|
struct kimage *image;
|
2016-11-29 12:45:48 +00:00
|
|
|
void *buffer;
|
2016-11-29 12:45:47 +00:00
|
|
|
unsigned long bufsz;
|
|
|
|
|
unsigned long mem;
|
|
|
|
|
unsigned long memsz;
|
|
|
|
|
unsigned long buf_align;
|
|
|
|
|
unsigned long buf_min;
|
|
|
|
|
unsigned long buf_max;
|
|
|
|
|
bool top_down;
|
kexec_file: allow to place kexec_buf randomly
Patch series "Support kdump with LUKS encryption by reusing LUKS volume
keys", v9.
LUKS is the standard for Linux disk encryption, widely adopted by users,
and in some cases, such as Confidential VMs, it is a requirement. With
kdump enabled, when the first kernel crashes, the system can boot into the
kdump/crash kernel to dump the memory image (i.e., /proc/vmcore) to a
specified target. However, there are two challenges when dumping vmcore
to a LUKS-encrypted device:
- Kdump kernel may not be able to decrypt the LUKS partition. For some
machines, a system administrator may not have a chance to enter the
password to decrypt the device in kdump initramfs after the 1st kernel
crashes; For cloud confidential VMs, depending on the policy the
kdump kernel may not be able to unseal the keys with TPM and the
console virtual keyboard is untrusted.
- LUKS2 by default use the memory-hard Argon2 key derivation function
which is quite memory-consuming compared to the limited memory reserved
for kdump. Take Fedora example, by default, only 256M is reserved for
systems having memory between 4G-64G. With LUKS enabled, ~1300M needs
to be reserved for kdump. Note if the memory reserved for kdump can't
be used by 1st kernel i.e. an user sees ~1300M memory missing in the
1st kernel.
Besides users (at least for Fedora) usually expect kdump to work out of
the box i.e. no manual password input or custom crashkernel value is
needed. And it doesn't make sense to derivate the keys again in kdump
kernel which seems to be redundant work.
This patchset addresses the above issues by making the LUKS volume keys
persistent for kdump kernel with the help of cryptsetup's new APIs
(--link-vk-to-keyring/--volume-key-keyring). Here is the life cycle of
the kdump copies of LUKS volume keys,
1. After the 1st kernel loads the initramfs during boot, systemd
use an user-input passphrase to de-crypt the LUKS volume keys
or TPM-sealed key and then save the volume keys to specified keyring
(using the --link-vk-to-keyring API) and the key will expire within
specified time.
2. A user space tool (kdump initramfs loader like kdump-utils) create
key items inside /sys/kernel/config/crash_dm_crypt_keys to inform
the 1st kernel which keys are needed.
3. When the kdump initramfs is loaded by the kexec_file_load
syscall, the 1st kernel will iterate created key items, save the
keys to kdump reserved memory.
4. When the 1st kernel crashes and the kdump initramfs is booted, the
kdump initramfs asks the kdump kernel to create a user key using the
key stored in kdump reserved memory by writing yes to
/sys/kernel/crash_dm_crypt_keys/restore. Then the LUKS encrypted
device is unlocked with libcryptsetup's --volume-key-keyring API.
5. The system gets rebooted to the 1st kernel after dumping vmcore to
the LUKS encrypted device is finished
After libcryptsetup saving the LUKS volume keys to specified keyring,
whoever takes this should be responsible for the safety of these copies of
keys. The keys will be saved in the memory area exclusively reserved for
kdump where even the 1st kernel has no direct access. And further more,
two additional protections are added,
- save the copy randomly in kdump reserved memory as suggested by Jan
- clear the _PAGE_PRESENT flag of the page that stores the copy as
suggested by Pingfan
This patchset only supports x86. There will be patches to support other
architectures once this patch set gets merged.
This patch (of 9):
Currently, kexec_buf is placed in order which means for the same machine,
the info in the kexec_buf is always located at the same position each time
the machine is booted. This may cause a risk for sensitive information
like LUKS volume key. Now struct kexec_buf has a new field random which
indicates it's supposed to be placed in a random position.
Note this feature is enabled only when CONFIG_CRASH_DUMP is enabled. So
it only takes effect for kdump and won't impact kexec reboot.
Link: https://lkml.kernel.org/r/20250502011246.99238-1-coxu@redhat.com
Link: https://lkml.kernel.org/r/20250502011246.99238-2-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Jan Pazdziora <jpazdziora@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-02 01:12:35 +00:00
|
|
|
#ifdef CONFIG_CRASH_DUMP
|
|
|
|
|
bool random;
|
|
|
|
|
#endif
|
2016-11-29 12:45:47 +00:00
|
|
|
};
|
|
|
|
|
|
kexec_file: allow to place kexec_buf randomly
Patch series "Support kdump with LUKS encryption by reusing LUKS volume
keys", v9.
LUKS is the standard for Linux disk encryption, widely adopted by users,
and in some cases, such as Confidential VMs, it is a requirement. With
kdump enabled, when the first kernel crashes, the system can boot into the
kdump/crash kernel to dump the memory image (i.e., /proc/vmcore) to a
specified target. However, there are two challenges when dumping vmcore
to a LUKS-encrypted device:
- Kdump kernel may not be able to decrypt the LUKS partition. For some
machines, a system administrator may not have a chance to enter the
password to decrypt the device in kdump initramfs after the 1st kernel
crashes; For cloud confidential VMs, depending on the policy the
kdump kernel may not be able to unseal the keys with TPM and the
console virtual keyboard is untrusted.
- LUKS2 by default use the memory-hard Argon2 key derivation function
which is quite memory-consuming compared to the limited memory reserved
for kdump. Take Fedora example, by default, only 256M is reserved for
systems having memory between 4G-64G. With LUKS enabled, ~1300M needs
to be reserved for kdump. Note if the memory reserved for kdump can't
be used by 1st kernel i.e. an user sees ~1300M memory missing in the
1st kernel.
Besides users (at least for Fedora) usually expect kdump to work out of
the box i.e. no manual password input or custom crashkernel value is
needed. And it doesn't make sense to derivate the keys again in kdump
kernel which seems to be redundant work.
This patchset addresses the above issues by making the LUKS volume keys
persistent for kdump kernel with the help of cryptsetup's new APIs
(--link-vk-to-keyring/--volume-key-keyring). Here is the life cycle of
the kdump copies of LUKS volume keys,
1. After the 1st kernel loads the initramfs during boot, systemd
use an user-input passphrase to de-crypt the LUKS volume keys
or TPM-sealed key and then save the volume keys to specified keyring
(using the --link-vk-to-keyring API) and the key will expire within
specified time.
2. A user space tool (kdump initramfs loader like kdump-utils) create
key items inside /sys/kernel/config/crash_dm_crypt_keys to inform
the 1st kernel which keys are needed.
3. When the kdump initramfs is loaded by the kexec_file_load
syscall, the 1st kernel will iterate created key items, save the
keys to kdump reserved memory.
4. When the 1st kernel crashes and the kdump initramfs is booted, the
kdump initramfs asks the kdump kernel to create a user key using the
key stored in kdump reserved memory by writing yes to
/sys/kernel/crash_dm_crypt_keys/restore. Then the LUKS encrypted
device is unlocked with libcryptsetup's --volume-key-keyring API.
5. The system gets rebooted to the 1st kernel after dumping vmcore to
the LUKS encrypted device is finished
After libcryptsetup saving the LUKS volume keys to specified keyring,
whoever takes this should be responsible for the safety of these copies of
keys. The keys will be saved in the memory area exclusively reserved for
kdump where even the 1st kernel has no direct access. And further more,
two additional protections are added,
- save the copy randomly in kdump reserved memory as suggested by Jan
- clear the _PAGE_PRESENT flag of the page that stores the copy as
suggested by Pingfan
This patchset only supports x86. There will be patches to support other
architectures once this patch set gets merged.
This patch (of 9):
Currently, kexec_buf is placed in order which means for the same machine,
the info in the kexec_buf is always located at the same position each time
the machine is booted. This may cause a risk for sensitive information
like LUKS volume key. Now struct kexec_buf has a new field random which
indicates it's supposed to be placed in a random position.
Note this feature is enabled only when CONFIG_CRASH_DUMP is enabled. So
it only takes effect for kdump and won't impact kexec reboot.
Link: https://lkml.kernel.org/r/20250502011246.99238-1-coxu@redhat.com
Link: https://lkml.kernel.org/r/20250502011246.99238-2-coxu@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Jan Pazdziora <jpazdziora@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Liu Pingfan <kernelfans@gmail.com>
Cc: Milan Broz <gmazyland@gmail.com>
Cc: Ondrej Kozina <okozina@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-02 01:12:35 +00:00
|
|
|
|
|
|
|
|
#ifdef CONFIG_CRASH_DUMP
|
|
|
|
|
static inline void kexec_random_range_start(unsigned long start,
|
|
|
|
|
unsigned long end,
|
|
|
|
|
struct kexec_buf *kbuf,
|
|
|
|
|
unsigned long *temp_start)
|
|
|
|
|
{
|
|
|
|
|
unsigned short i;
|
|
|
|
|
|
|
|
|
|
if (kbuf->random) {
|
|
|
|
|
get_random_bytes(&i, sizeof(unsigned short));
|
|
|
|
|
*temp_start = start + (end - start) / USHRT_MAX * i;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
static inline void kexec_random_range_start(unsigned long start,
|
|
|
|
|
unsigned long end,
|
|
|
|
|
struct kexec_buf *kbuf,
|
|
|
|
|
unsigned long *temp_start)
|
|
|
|
|
{}
|
|
|
|
|
#endif
|
|
|
|
|
|
2018-04-13 22:36:43 +00:00
|
|
|
int kexec_load_purgatory(struct kimage *image, struct kexec_buf *kbuf);
|
|
|
|
|
int kexec_purgatory_get_set_symbol(struct kimage *image, const char *name,
|
|
|
|
|
void *buf, unsigned int size,
|
|
|
|
|
bool get_value);
|
|
|
|
|
void *kexec_purgatory_get_symbol_addr(struct kimage *image, const char *name);
|
2022-07-01 07:34:04 +00:00
|
|
|
|
|
|
|
|
#ifndef arch_kexec_kernel_image_probe
|
|
|
|
|
static inline int
|
|
|
|
|
arch_kexec_kernel_image_probe(struct kimage *image, void *buf, unsigned long buf_len)
|
|
|
|
|
{
|
|
|
|
|
return kexec_image_probe_default(image, buf, buf_len);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef arch_kimage_file_post_load_cleanup
|
|
|
|
|
static inline int arch_kimage_file_post_load_cleanup(struct kimage *image)
|
|
|
|
|
{
|
|
|
|
|
return kexec_image_post_load_cleanup_default(image);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2025-01-31 11:38:26 +00:00
|
|
|
#ifndef arch_check_excluded_range
|
|
|
|
|
static inline int arch_check_excluded_range(struct kimage *image,
|
|
|
|
|
unsigned long start,
|
|
|
|
|
unsigned long end)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2022-07-14 13:40:25 +00:00
|
|
|
#ifdef CONFIG_KEXEC_SIG
|
|
|
|
|
#ifdef CONFIG_SIGNED_PE_FILE_VERIFICATION
|
|
|
|
|
int kexec_kernel_verify_pe_sig(const char *kernel, unsigned long kernel_len);
|
|
|
|
|
#endif
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-11-29 12:45:48 +00:00
|
|
|
extern int kexec_add_buffer(struct kexec_buf *kbuf);
|
2016-11-29 12:45:49 +00:00
|
|
|
int kexec_locate_mem_hole(struct kexec_buf *kbuf);
|
2018-04-13 22:36:06 +00:00
|
|
|
|
2022-07-01 07:34:04 +00:00
|
|
|
#ifndef arch_kexec_locate_mem_hole
|
|
|
|
|
/**
|
|
|
|
|
* arch_kexec_locate_mem_hole - Find free memory to place the segments.
|
|
|
|
|
* @kbuf: Parameters for the memory search.
|
|
|
|
|
*
|
|
|
|
|
* On success, kbuf->mem will have the start address of the memory region found.
|
|
|
|
|
*
|
|
|
|
|
* Return: 0 on success, negative errno on error.
|
|
|
|
|
*/
|
|
|
|
|
static inline int arch_kexec_locate_mem_hole(struct kexec_buf *kbuf)
|
|
|
|
|
{
|
|
|
|
|
return kexec_locate_mem_hole(kbuf);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2022-05-19 09:12:37 +00:00
|
|
|
#ifndef arch_kexec_apply_relocations_add
|
|
|
|
|
/*
|
|
|
|
|
* arch_kexec_apply_relocations_add - apply relocations of type RELA
|
|
|
|
|
* @pi: Purgatory to be relocated.
|
|
|
|
|
* @section: Section relocations applying to.
|
|
|
|
|
* @relsec: Section containing RELAs.
|
|
|
|
|
* @symtab: Corresponding symtab.
|
|
|
|
|
*
|
|
|
|
|
* Return: 0 on success, negative errno on error.
|
|
|
|
|
*/
|
|
|
|
|
static inline int
|
|
|
|
|
arch_kexec_apply_relocations_add(struct purgatory_info *pi, Elf_Shdr *section,
|
|
|
|
|
const Elf_Shdr *relsec, const Elf_Shdr *symtab)
|
|
|
|
|
{
|
|
|
|
|
pr_err("RELA relocation unsupported.\n");
|
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef arch_kexec_apply_relocations
|
|
|
|
|
/*
|
|
|
|
|
* arch_kexec_apply_relocations - apply relocations of type REL
|
|
|
|
|
* @pi: Purgatory to be relocated.
|
|
|
|
|
* @section: Section relocations applying to.
|
|
|
|
|
* @relsec: Section containing RELs.
|
|
|
|
|
* @symtab: Corresponding symtab.
|
|
|
|
|
*
|
|
|
|
|
* Return: 0 on success, negative errno on error.
|
|
|
|
|
*/
|
|
|
|
|
static inline int
|
|
|
|
|
arch_kexec_apply_relocations(struct purgatory_info *pi, Elf_Shdr *section,
|
|
|
|
|
const Elf_Shdr *relsec, const Elf_Shdr *symtab)
|
|
|
|
|
{
|
|
|
|
|
pr_err("REL relocation unsupported.\n");
|
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2016-11-29 12:45:47 +00:00
|
|
|
#endif /* CONFIG_KEXEC_FILE */
|
2016-01-20 23:00:36 +00:00
|
|
|
|
2019-08-23 19:49:13 +00:00
|
|
|
#ifdef CONFIG_KEXEC_ELF
|
|
|
|
|
struct kexec_elf_info {
|
|
|
|
|
/*
|
|
|
|
|
* Where the ELF binary contents are kept.
|
|
|
|
|
* Memory managed by the user of the struct.
|
|
|
|
|
*/
|
|
|
|
|
const char *buffer;
|
|
|
|
|
|
|
|
|
|
const struct elfhdr *ehdr;
|
|
|
|
|
const struct elf_phdr *proghdrs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int kexec_build_elf_info(const char *buf, size_t len, struct elfhdr *ehdr,
|
|
|
|
|
struct kexec_elf_info *elf_info);
|
|
|
|
|
|
|
|
|
|
int kexec_elf_load(struct kimage *image, struct elfhdr *ehdr,
|
|
|
|
|
struct kexec_elf_info *elf_info,
|
|
|
|
|
struct kexec_buf *kbuf,
|
|
|
|
|
unsigned long *lowest_load_addr);
|
|
|
|
|
|
|
|
|
|
void kexec_free_elf_info(struct kexec_elf_info *elf_info);
|
|
|
|
|
int kexec_elf_probe(const char *buf, unsigned long len);
|
|
|
|
|
#endif
|
2005-06-25 21:57:52 +00:00
|
|
|
struct kimage {
|
|
|
|
|
kimage_entry_t head;
|
|
|
|
|
kimage_entry_t *entry;
|
|
|
|
|
kimage_entry_t *last_entry;
|
|
|
|
|
|
|
|
|
|
unsigned long start;
|
|
|
|
|
struct page *control_code_page;
|
2008-07-26 02:45:07 +00:00
|
|
|
struct page *swap_page;
|
kdump: protect vmcoreinfo data under the crash memory
Currently vmcoreinfo data is updated at boot time subsys_initcall(), it
has the risk of being modified by some wrong code during system is
running.
As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on,
when using "crash", "makedumpfile", etc utility to parse this vmcore, we
probably will get "Segmentation fault" or other unexpected errors.
E.g. 1) wrong code overwrites vmcoreinfo_data; 2) further crashes the
system; 3) trigger kdump, then we obviously will fail to recognize the
crash context correctly due to the corrupted vmcoreinfo.
Now except for vmcoreinfo, all the crash data is well
protected(including the cpu note which is fully updated in the crash
path, thus its correctness is guaranteed). Given that vmcoreinfo data
is a large chunk prepared for kdump, we better protect it as well.
To solve this, we relocate and copy vmcoreinfo_data to the crash memory
when kdump is loading via kexec syscalls. Because the whole crash
memory will be protected by existing arch_kexec_protect_crashkres()
mechanism, we naturally protect vmcoreinfo_data from write(even read)
access under kernel direct mapping after kdump is loaded.
Since kdump is usually loaded at the very early stage after boot, we can
trust the correctness of the vmcoreinfo data copied.
On the other hand, we still need to operate the vmcoreinfo safe copy
when crash happens to generate vmcoreinfo_note again, we rely on vmap()
to map out a new kernel virtual address and update to use this new one
instead in the following crash_save_vmcoreinfo().
BTW, we do not touch vmcoreinfo_note, because it will be fully updated
using the protected vmcoreinfo_data after crash which is surely correct
just like the cpu crash note.
Link: http://lkml.kernel.org/r/1493281021-20737-3-git-send-email-xlpang@redhat.com
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Tested-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Dave Young <dyoung@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-07-12 21:33:21 +00:00
|
|
|
void *vmcoreinfo_data_copy; /* locates in the crash memory */
|
2005-06-25 21:57:52 +00:00
|
|
|
|
|
|
|
|
unsigned long nr_segments;
|
|
|
|
|
struct kexec_segment segment[KEXEC_SEGMENT_MAX];
|
|
|
|
|
|
|
|
|
|
struct list_head control_pages;
|
|
|
|
|
struct list_head dest_pages;
|
2014-08-08 21:25:43 +00:00
|
|
|
struct list_head unusable_pages;
|
2005-06-25 21:57:52 +00:00
|
|
|
|
|
|
|
|
/* Address of next control page to allocate for crash kernels. */
|
|
|
|
|
unsigned long control_page;
|
|
|
|
|
|
|
|
|
|
/* Flags to indicate special processing */
|
|
|
|
|
unsigned int type : 1;
|
|
|
|
|
#define KEXEC_TYPE_DEFAULT 0
|
|
|
|
|
#define KEXEC_TYPE_CRASH 1
|
2008-07-26 02:45:07 +00:00
|
|
|
unsigned int preserve_context : 1;
|
2014-08-08 21:25:57 +00:00
|
|
|
/* If set, we are using file mode kexec syscall */
|
|
|
|
|
unsigned int file_mode:1;
|
crash: hotplug support for kexec_load()
The hotplug support for kexec_load() requires changes to the userspace
kexec-tools and a little extra help from the kernel.
Given a kdump capture kernel loaded via kexec_load(), and a subsequent
hotplug event, the crash hotplug handler finds the elfcorehdr and rewrites
it to reflect the hotplug change. That is the desired outcome, however,
at kernel panic time, the purgatory integrity check fails (because the
elfcorehdr changed), and the capture kernel does not boot and no vmcore is
generated.
Therefore, the userspace kexec-tools/kexec must indicate to the kernel
that the elfcorehdr can be modified (because the kexec excluded the
elfcorehdr from the digest, and sized the elfcorehdr memory buffer
appropriately).
To facilitate hotplug support with kexec_load():
- a new kexec flag KEXEC_UPATE_ELFCOREHDR indicates that it is
safe for the kernel to modify the kexec_load()'d elfcorehdr
- the /sys/kernel/crash_elfcorehdr_size node communicates the
preferred size of the elfcorehdr memory buffer
- The sysfs crash_hotplug nodes (ie.
/sys/devices/system/[cpu|memory]/crash_hotplug) dynamically
take into account kexec_file_load() vs kexec_load() and
KEXEC_UPDATE_ELFCOREHDR.
This is critical so that the udev rule processing of crash_hotplug
is all that is needed to determine if the userspace unload-then-load
of the kdump image is to be skipped, or not. The proposed udev
rule change looks like:
# The kernel updates the crash elfcorehdr for CPU and memory changes
SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
SUBSYSTEM=="memory", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
The table below indicates the behavior of kexec_load()'d kdump image
updates (with the new udev crash_hotplug rule in place):
Kernel |Kexec
-------+-----+----
Old |Old |New
| a | a
-------+-----+----
New | a | b
-------+-----+----
where kexec 'old' and 'new' delineate kexec-tools has the needed
modifications for the crash hotplug feature, and kernel 'old' and 'new'
delineate the kernel supports this crash hotplug feature.
Behavior 'a' indicates the unload-then-reload of the entire kdump image.
For the kexec 'old' column, the unload-then-reload occurs due to the
missing flag KEXEC_UPDATE_ELFCOREHDR. An 'old' kernel (with 'new' kexec)
does not present the crash_hotplug sysfs node, which leads to the
unload-then-reload of the kdump image.
Behavior 'b' indicates the desired optimized behavior of the kernel
directly modifying the elfcorehdr and avoiding the unload-then-reload of
the kdump image.
If the udev rule is not updated with crash_hotplug node check, then no
matter any combination of kernel or kexec is new or old, the kdump image
continues to be unload-then-reload on hotplug changes.
To fully support crash hotplug feature, there needs to be a rollout of
kernel, kexec-tools and udev rule changes. However, the order of the
rollout of these pieces does not matter; kexec_load()'d kdump images still
function for hotplug as-is.
Link: https://lkml.kernel.org/r/20230814214446.6659-7-eric.devolder@oracle.com
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Suggested-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Akhil Raj <lf32.dev@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Weißschuh <linux@weissschuh.net>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-14 21:44:44 +00:00
|
|
|
#ifdef CONFIG_CRASH_HOTPLUG
|
2024-03-26 05:54:09 +00:00
|
|
|
/* If set, it is safe to update kexec segments that are
|
|
|
|
|
* excluded from SHA calculation.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int hotplug_support:1;
|
crash: hotplug support for kexec_load()
The hotplug support for kexec_load() requires changes to the userspace
kexec-tools and a little extra help from the kernel.
Given a kdump capture kernel loaded via kexec_load(), and a subsequent
hotplug event, the crash hotplug handler finds the elfcorehdr and rewrites
it to reflect the hotplug change. That is the desired outcome, however,
at kernel panic time, the purgatory integrity check fails (because the
elfcorehdr changed), and the capture kernel does not boot and no vmcore is
generated.
Therefore, the userspace kexec-tools/kexec must indicate to the kernel
that the elfcorehdr can be modified (because the kexec excluded the
elfcorehdr from the digest, and sized the elfcorehdr memory buffer
appropriately).
To facilitate hotplug support with kexec_load():
- a new kexec flag KEXEC_UPATE_ELFCOREHDR indicates that it is
safe for the kernel to modify the kexec_load()'d elfcorehdr
- the /sys/kernel/crash_elfcorehdr_size node communicates the
preferred size of the elfcorehdr memory buffer
- The sysfs crash_hotplug nodes (ie.
/sys/devices/system/[cpu|memory]/crash_hotplug) dynamically
take into account kexec_file_load() vs kexec_load() and
KEXEC_UPDATE_ELFCOREHDR.
This is critical so that the udev rule processing of crash_hotplug
is all that is needed to determine if the userspace unload-then-load
of the kdump image is to be skipped, or not. The proposed udev
rule change looks like:
# The kernel updates the crash elfcorehdr for CPU and memory changes
SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
SUBSYSTEM=="memory", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
The table below indicates the behavior of kexec_load()'d kdump image
updates (with the new udev crash_hotplug rule in place):
Kernel |Kexec
-------+-----+----
Old |Old |New
| a | a
-------+-----+----
New | a | b
-------+-----+----
where kexec 'old' and 'new' delineate kexec-tools has the needed
modifications for the crash hotplug feature, and kernel 'old' and 'new'
delineate the kernel supports this crash hotplug feature.
Behavior 'a' indicates the unload-then-reload of the entire kdump image.
For the kexec 'old' column, the unload-then-reload occurs due to the
missing flag KEXEC_UPDATE_ELFCOREHDR. An 'old' kernel (with 'new' kexec)
does not present the crash_hotplug sysfs node, which leads to the
unload-then-reload of the kdump image.
Behavior 'b' indicates the desired optimized behavior of the kernel
directly modifying the elfcorehdr and avoiding the unload-then-reload of
the kdump image.
If the udev rule is not updated with crash_hotplug node check, then no
matter any combination of kernel or kexec is new or old, the kdump image
continues to be unload-then-reload on hotplug changes.
To fully support crash hotplug feature, there needs to be a rollout of
kernel, kexec-tools and udev rule changes. However, the order of the
rollout of these pieces does not matter; kexec_load()'d kdump images still
function for hotplug as-is.
Link: https://lkml.kernel.org/r/20230814214446.6659-7-eric.devolder@oracle.com
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Suggested-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Akhil Raj <lf32.dev@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Weißschuh <linux@weissschuh.net>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-14 21:44:44 +00:00
|
|
|
#endif
|
2008-10-31 01:48:08 +00:00
|
|
|
|
|
|
|
|
#ifdef ARCH_HAS_KIMAGE_ARCH
|
|
|
|
|
struct kimage_arch arch;
|
|
|
|
|
#endif
|
2014-08-08 21:25:57 +00:00
|
|
|
|
2016-01-20 23:00:36 +00:00
|
|
|
#ifdef CONFIG_KEXEC_FILE
|
2014-08-08 21:25:57 +00:00
|
|
|
/* Additional fields for file based kexec syscall */
|
|
|
|
|
void *kernel_buf;
|
|
|
|
|
unsigned long kernel_buf_len;
|
|
|
|
|
|
|
|
|
|
void *initrd_buf;
|
|
|
|
|
unsigned long initrd_buf_len;
|
|
|
|
|
|
|
|
|
|
char *cmdline_buf;
|
|
|
|
|
unsigned long cmdline_buf_len;
|
|
|
|
|
|
|
|
|
|
/* File operations provided by image loader */
|
2018-04-13 22:35:49 +00:00
|
|
|
const struct kexec_file_ops *fops;
|
2014-08-08 21:25:57 +00:00
|
|
|
|
|
|
|
|
/* Image loader handling the kernel can store a pointer here */
|
|
|
|
|
void *image_loader_data;
|
2014-08-08 21:26:04 +00:00
|
|
|
|
|
|
|
|
/* Information for loading purgatory */
|
|
|
|
|
struct purgatory_info purgatory_info;
|
2016-01-20 23:00:36 +00:00
|
|
|
#endif
|
2021-02-04 17:49:51 +00:00
|
|
|
|
crash: add generic infrastructure for crash hotplug support
To support crash hotplug, a mechanism is needed to update the crash
elfcorehdr upon CPU or memory changes (eg. hot un/plug or off/ onlining).
The crash elfcorehdr describes the CPUs and memory to be written into the
vmcore.
To track CPU changes, callbacks are registered with the cpuhp mechanism
via cpuhp_setup_state_nocalls(CPUHP_BP_PREPARE_DYN). The crash hotplug
elfcorehdr update has no explicit ordering requirement (relative to other
cpuhp states), so meets the criteria for utilizing CPUHP_BP_PREPARE_DYN.
CPUHP_BP_PREPARE_DYN is a dynamic state and avoids the need to introduce a
new state for crash hotplug. Also, CPUHP_BP_PREPARE_DYN is the last state
in the PREPARE group, just prior to the STARTING group, which is very
close to the CPU starting up in a plug/online situation, or stopping in a
unplug/ offline situation. This minimizes the window of time during an
actual plug/online or unplug/offline situation in which the elfcorehdr
would be inaccurate. Note that for a CPU being unplugged or offlined, the
CPU will still be present in the list of CPUs generated by
crash_prepare_elf64_headers(). However, there is no need to explicitly
omit the CPU, see justification in 'crash: change
crash_prepare_elf64_headers() to for_each_possible_cpu()'.
To track memory changes, a notifier is registered to capture the memblock
MEM_ONLINE and MEM_OFFLINE events via register_memory_notifier().
The CPU callbacks and memory notifiers invoke crash_handle_hotplug_event()
which performs needed tasks and then dispatches the event to the
architecture specific arch_crash_handle_hotplug_event() to update the
elfcorehdr with the current state of CPUs and memory. During the process,
the kexec_lock is held.
Link: https://lkml.kernel.org/r/20230814214446.6659-3-eric.devolder@oracle.com
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Akhil Raj <lf32.dev@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Weißschuh <linux@weissschuh.net>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-08-14 21:44:40 +00:00
|
|
|
#ifdef CONFIG_CRASH_HOTPLUG
|
|
|
|
|
int hp_action;
|
|
|
|
|
int elfcorehdr_index;
|
|
|
|
|
bool elfcorehdr_updated;
|
|
|
|
|
#endif
|
|
|
|
|
|
2021-02-04 17:49:51 +00:00
|
|
|
#ifdef CONFIG_IMA_KEXEC
|
|
|
|
|
/* Virtual address of IMA measurement buffer for kexec syscall */
|
|
|
|
|
void *ima_buffer;
|
2021-02-21 17:49:25 +00:00
|
|
|
|
|
|
|
|
phys_addr_t ima_buffer_addr;
|
|
|
|
|
size_t ima_buffer_size;
|
2025-04-21 22:25:10 +00:00
|
|
|
|
|
|
|
|
unsigned long ima_segment_index;
|
|
|
|
|
bool is_ima_segment_index_set;
|
2021-02-04 17:49:51 +00:00
|
|
|
#endif
|
2021-02-21 17:49:18 +00:00
|
|
|
|
2025-05-09 07:46:25 +00:00
|
|
|
struct {
|
|
|
|
|
struct kexec_segment *scratch;
|
|
|
|
|
phys_addr_t fdt;
|
|
|
|
|
} kho;
|
|
|
|
|
|
2021-02-21 17:49:18 +00:00
|
|
|
/* Core ELF header buffer */
|
|
|
|
|
void *elf_headers;
|
|
|
|
|
unsigned long elf_headers_sz;
|
|
|
|
|
unsigned long elf_load_addr;
|
2025-05-02 01:12:37 +00:00
|
|
|
|
|
|
|
|
/* dm crypt keys buffer */
|
|
|
|
|
unsigned long dm_crypt_keys_addr;
|
|
|
|
|
unsigned long dm_crypt_keys_sz;
|
2014-08-08 21:25:57 +00:00
|
|
|
};
|
2005-06-25 21:57:52 +00:00
|
|
|
|
|
|
|
|
/* kexec interface functions */
|
2008-07-26 02:45:07 +00:00
|
|
|
extern void machine_kexec(struct kimage *image);
|
2005-06-25 21:57:52 +00:00
|
|
|
extern int machine_kexec_prepare(struct kimage *image);
|
|
|
|
|
extern void machine_kexec_cleanup(struct kimage *image);
|
2008-07-26 02:45:07 +00:00
|
|
|
extern int kernel_kexec(void);
|
2005-06-25 21:58:28 +00:00
|
|
|
extern struct page *kimage_alloc_control_pages(struct kimage *image,
|
|
|
|
|
unsigned int order);
|
2022-07-01 07:34:05 +00:00
|
|
|
|
|
|
|
|
#ifndef machine_kexec_post_load
|
|
|
|
|
static inline int machine_kexec_post_load(struct kimage *image) { return 0; }
|
|
|
|
|
#endif
|
2021-02-19 19:51:42 +00:00
|
|
|
|
2005-06-25 21:57:52 +00:00
|
|
|
extern struct kimage *kexec_image;
|
2006-06-23 09:05:07 +00:00
|
|
|
extern struct kimage *kexec_crash_image;
|
2023-01-04 14:38:47 +00:00
|
|
|
|
2023-01-04 14:38:48 +00:00
|
|
|
bool kexec_load_permitted(int kexec_image_type);
|
2005-06-25 21:57:52 +00:00
|
|
|
|
2006-12-07 17:51:35 +00:00
|
|
|
#ifndef kexec_flush_icache_page
|
|
|
|
|
#define kexec_flush_icache_page(page)
|
|
|
|
|
#endif
|
|
|
|
|
|
2008-07-26 02:45:07 +00:00
|
|
|
/* List of defined/legal kexec flags */
|
|
|
|
|
#ifndef CONFIG_KEXEC_JUMP
|
2024-03-26 05:54:09 +00:00
|
|
|
#define KEXEC_FLAGS (KEXEC_ON_CRASH | KEXEC_UPDATE_ELFCOREHDR | KEXEC_CRASH_HOTPLUG_SUPPORT)
|
2008-07-26 02:45:07 +00:00
|
|
|
#else
|
2024-03-26 05:54:09 +00:00
|
|
|
#define KEXEC_FLAGS (KEXEC_ON_CRASH | KEXEC_PRESERVE_CONTEXT | KEXEC_UPDATE_ELFCOREHDR | \
|
|
|
|
|
KEXEC_CRASH_HOTPLUG_SUPPORT)
|
2008-07-26 02:45:07 +00:00
|
|
|
#endif
|
2005-06-25 21:57:52 +00:00
|
|
|
|
2014-08-08 21:25:57 +00:00
|
|
|
/* List of defined/legal kexec file flags */
|
|
|
|
|
#define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
|
kexec_file: add kexec_file flag to control debug printing
Patch series "kexec_file: print out debugging message if required", v4.
Currently, specifying '-d' on kexec command will print a lot of debugging
informationabout kexec/kdump loading with kexec_load interface.
However, kexec_file_load prints nothing even though '-d' is specified.
It's very inconvenient to debug or analyze the kexec/kdump loading when
something wrong happened with kexec/kdump itself or develper want to check
the kexec/kdump loading.
In this patchset, a kexec_file flag is KEXEC_FILE_DEBUG added and checked
in code. If it's passed in, debugging message of kexec_file code will be
printed out and can be seen from console and dmesg. Otherwise, the
debugging message is printed like beofre when pr_debug() is taken.
Note:
****
=====
1) The code in kexec-tools utility also need be changed to support
passing KEXEC_FILE_DEBUG to kernel when 'kexec -s -d' is specified.
The patch link is here:
=========
[PATCH] kexec_file: add kexec_file flag to support debug printing
http://lists.infradead.org/pipermail/kexec/2023-November/028505.html
2) s390 also has kexec_file code, while I am not sure what debugging
information is necessary. So leave it to s390 developer.
Test:
****
====
Testing was done in v1 on x86_64 and arm64. For v4, tested on x86_64
again. And on x86_64, the printed messages look like below:
--------------------------------------------------------------
kexec measurement buffer for the loaded kernel at 0x207fffe000.
Loaded purgatory at 0x207fff9000
Loaded boot_param, command line and misc at 0x207fff3000 bufsz=0x1180 memsz=0x1180
Loaded 64bit kernel at 0x207c000000 bufsz=0xc88200 memsz=0x3c4a000
Loaded initrd at 0x2079e79000 bufsz=0x2186280 memsz=0x2186280
Final command line is: root=/dev/mapper/fedora_intel--knightslanding--lb--02-root ro
rd.lvm.lv=fedora_intel-knightslanding-lb-02/root console=ttyS0,115200N81 crashkernel=256M
E820 memmap:
0000000000000000-000000000009a3ff (1)
000000000009a400-000000000009ffff (2)
00000000000e0000-00000000000fffff (2)
0000000000100000-000000006ff83fff (1)
000000006ff84000-000000007ac50fff (2)
......
000000207fff6150-000000207fff615f (128)
000000207fff6160-000000207fff714f (1)
000000207fff7150-000000207fff715f (128)
000000207fff7160-000000207fff814f (1)
000000207fff8150-000000207fff815f (128)
000000207fff8160-000000207fffffff (1)
nr_segments = 5
segment[0]: buf=0x000000004e5ece74 bufsz=0x211 mem=0x207fffe000 memsz=0x1000
segment[1]: buf=0x000000009e871498 bufsz=0x4000 mem=0x207fff9000 memsz=0x5000
segment[2]: buf=0x00000000d879f1fe bufsz=0x1180 mem=0x207fff3000 memsz=0x2000
segment[3]: buf=0x000000001101cd86 bufsz=0xc88200 mem=0x207c000000 memsz=0x3c4a000
segment[4]: buf=0x00000000c6e38ac7 bufsz=0x2186280 mem=0x2079e79000 memsz=0x2187000
kexec_file_load: type:0, start:0x207fff91a0 head:0x109e004002 flags:0x8
---------------------------------------------------------------------------
This patch (of 7):
When specifying 'kexec -c -d', kexec_load interface will print loading
information, e.g the regions where kernel/initrd/purgatory/cmdline are
put, the memmap passed to 2nd kernel taken as system RAM ranges, and
printing all contents of struct kexec_segment, etc. These are very
helpful for analyzing or positioning what's happening when kexec/kdump
itself failed. The debugging printing for kexec_load interface is made in
user space utility kexec-tools.
Whereas, with kexec_file_load interface, 'kexec -s -d' print nothing.
Because kexec_file code is mostly implemented in kernel space, and the
debugging printing functionality is missed. It's not convenient when
debugging kexec/kdump loading and jumping with kexec_file_load interface.
Now add KEXEC_FILE_DEBUG to kexec_file flag to control the debugging
message printing. And add global variable kexec_file_dbg_print and macro
kexec_dprintk() to facilitate the printing.
This is a preparation, later kexec_dprintk() will be used to replace the
existing pr_debug(). Once 'kexec -s -d' is specified, it will print out
kexec/kdump loading information. If '-d' is not specified, it regresses
to pr_debug().
Link: https://lkml.kernel.org/r/20231213055747.61826-1-bhe@redhat.com
Link: https://lkml.kernel.org/r/20231213055747.61826-2-bhe@redhat.com
Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: Conor Dooley <conor@kernel.org>
Cc: Joe Perches <joe@perches.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-12-13 05:57:41 +00:00
|
|
|
KEXEC_FILE_NO_INITRAMFS | KEXEC_FILE_DEBUG)
|
2014-08-08 21:25:57 +00:00
|
|
|
|
2013-11-27 22:19:25 +00:00
|
|
|
/* flag to track if kexec reboot is in progress */
|
|
|
|
|
extern bool kexec_in_progress;
|
|
|
|
|
|
2016-08-02 21:06:04 +00:00
|
|
|
#ifndef page_to_boot_pfn
|
|
|
|
|
static inline unsigned long page_to_boot_pfn(struct page *page)
|
|
|
|
|
{
|
|
|
|
|
return page_to_pfn(page);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef boot_pfn_to_page
|
|
|
|
|
static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
|
|
|
|
|
{
|
|
|
|
|
return pfn_to_page(boot_pfn);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef phys_to_boot_phys
|
|
|
|
|
static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
|
|
|
|
|
{
|
|
|
|
|
return phys;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef boot_phys_to_phys
|
|
|
|
|
static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
|
|
|
|
|
{
|
|
|
|
|
return boot_phys;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2022-07-01 07:34:05 +00:00
|
|
|
#ifndef crash_free_reserved_phys_range
|
|
|
|
|
static inline void crash_free_reserved_phys_range(unsigned long begin, unsigned long end)
|
|
|
|
|
{
|
|
|
|
|
unsigned long addr;
|
|
|
|
|
|
|
|
|
|
for (addr = begin; addr < end; addr += PAGE_SIZE)
|
|
|
|
|
free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-08-02 21:06:04 +00:00
|
|
|
static inline unsigned long virt_to_boot_phys(void *addr)
|
|
|
|
|
{
|
|
|
|
|
return phys_to_boot_phys(__pa((unsigned long)addr));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void *boot_phys_to_virt(unsigned long entry)
|
|
|
|
|
{
|
|
|
|
|
return phys_to_virt(boot_phys_to_phys(entry));
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-17 21:10:28 +00:00
|
|
|
#ifndef arch_kexec_post_alloc_pages
|
|
|
|
|
static inline int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages, gfp_t gfp) { return 0; }
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef arch_kexec_pre_free_pages
|
|
|
|
|
static inline void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages) { }
|
|
|
|
|
#endif
|
|
|
|
|
|
kexec_file: add kexec_file flag to control debug printing
Patch series "kexec_file: print out debugging message if required", v4.
Currently, specifying '-d' on kexec command will print a lot of debugging
informationabout kexec/kdump loading with kexec_load interface.
However, kexec_file_load prints nothing even though '-d' is specified.
It's very inconvenient to debug or analyze the kexec/kdump loading when
something wrong happened with kexec/kdump itself or develper want to check
the kexec/kdump loading.
In this patchset, a kexec_file flag is KEXEC_FILE_DEBUG added and checked
in code. If it's passed in, debugging message of kexec_file code will be
printed out and can be seen from console and dmesg. Otherwise, the
debugging message is printed like beofre when pr_debug() is taken.
Note:
****
=====
1) The code in kexec-tools utility also need be changed to support
passing KEXEC_FILE_DEBUG to kernel when 'kexec -s -d' is specified.
The patch link is here:
=========
[PATCH] kexec_file: add kexec_file flag to support debug printing
http://lists.infradead.org/pipermail/kexec/2023-November/028505.html
2) s390 also has kexec_file code, while I am not sure what debugging
information is necessary. So leave it to s390 developer.
Test:
****
====
Testing was done in v1 on x86_64 and arm64. For v4, tested on x86_64
again. And on x86_64, the printed messages look like below:
--------------------------------------------------------------
kexec measurement buffer for the loaded kernel at 0x207fffe000.
Loaded purgatory at 0x207fff9000
Loaded boot_param, command line and misc at 0x207fff3000 bufsz=0x1180 memsz=0x1180
Loaded 64bit kernel at 0x207c000000 bufsz=0xc88200 memsz=0x3c4a000
Loaded initrd at 0x2079e79000 bufsz=0x2186280 memsz=0x2186280
Final command line is: root=/dev/mapper/fedora_intel--knightslanding--lb--02-root ro
rd.lvm.lv=fedora_intel-knightslanding-lb-02/root console=ttyS0,115200N81 crashkernel=256M
E820 memmap:
0000000000000000-000000000009a3ff (1)
000000000009a400-000000000009ffff (2)
00000000000e0000-00000000000fffff (2)
0000000000100000-000000006ff83fff (1)
000000006ff84000-000000007ac50fff (2)
......
000000207fff6150-000000207fff615f (128)
000000207fff6160-000000207fff714f (1)
000000207fff7150-000000207fff715f (128)
000000207fff7160-000000207fff814f (1)
000000207fff8150-000000207fff815f (128)
000000207fff8160-000000207fffffff (1)
nr_segments = 5
segment[0]: buf=0x000000004e5ece74 bufsz=0x211 mem=0x207fffe000 memsz=0x1000
segment[1]: buf=0x000000009e871498 bufsz=0x4000 mem=0x207fff9000 memsz=0x5000
segment[2]: buf=0x00000000d879f1fe bufsz=0x1180 mem=0x207fff3000 memsz=0x2000
segment[3]: buf=0x000000001101cd86 bufsz=0xc88200 mem=0x207c000000 memsz=0x3c4a000
segment[4]: buf=0x00000000c6e38ac7 bufsz=0x2186280 mem=0x2079e79000 memsz=0x2187000
kexec_file_load: type:0, start:0x207fff91a0 head:0x109e004002 flags:0x8
---------------------------------------------------------------------------
This patch (of 7):
When specifying 'kexec -c -d', kexec_load interface will print loading
information, e.g the regions where kernel/initrd/purgatory/cmdline are
put, the memmap passed to 2nd kernel taken as system RAM ranges, and
printing all contents of struct kexec_segment, etc. These are very
helpful for analyzing or positioning what's happening when kexec/kdump
itself failed. The debugging printing for kexec_load interface is made in
user space utility kexec-tools.
Whereas, with kexec_file_load interface, 'kexec -s -d' print nothing.
Because kexec_file code is mostly implemented in kernel space, and the
debugging printing functionality is missed. It's not convenient when
debugging kexec/kdump loading and jumping with kexec_file_load interface.
Now add KEXEC_FILE_DEBUG to kexec_file flag to control the debugging
message printing. And add global variable kexec_file_dbg_print and macro
kexec_dprintk() to facilitate the printing.
This is a preparation, later kexec_dprintk() will be used to replace the
existing pr_debug(). Once 'kexec -s -d' is specified, it will print out
kexec/kdump loading information. If '-d' is not specified, it regresses
to pr_debug().
Link: https://lkml.kernel.org/r/20231213055747.61826-1-bhe@redhat.com
Link: https://lkml.kernel.org/r/20231213055747.61826-2-bhe@redhat.com
Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: Conor Dooley <conor@kernel.org>
Cc: Joe Perches <joe@perches.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-12-13 05:57:41 +00:00
|
|
|
extern bool kexec_file_dbg_print;
|
|
|
|
|
|
2024-04-09 04:22:38 +00:00
|
|
|
#define kexec_dprintk(fmt, arg...) \
|
|
|
|
|
do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0)
|
kexec_file: add kexec_file flag to control debug printing
Patch series "kexec_file: print out debugging message if required", v4.
Currently, specifying '-d' on kexec command will print a lot of debugging
informationabout kexec/kdump loading with kexec_load interface.
However, kexec_file_load prints nothing even though '-d' is specified.
It's very inconvenient to debug or analyze the kexec/kdump loading when
something wrong happened with kexec/kdump itself or develper want to check
the kexec/kdump loading.
In this patchset, a kexec_file flag is KEXEC_FILE_DEBUG added and checked
in code. If it's passed in, debugging message of kexec_file code will be
printed out and can be seen from console and dmesg. Otherwise, the
debugging message is printed like beofre when pr_debug() is taken.
Note:
****
=====
1) The code in kexec-tools utility also need be changed to support
passing KEXEC_FILE_DEBUG to kernel when 'kexec -s -d' is specified.
The patch link is here:
=========
[PATCH] kexec_file: add kexec_file flag to support debug printing
http://lists.infradead.org/pipermail/kexec/2023-November/028505.html
2) s390 also has kexec_file code, while I am not sure what debugging
information is necessary. So leave it to s390 developer.
Test:
****
====
Testing was done in v1 on x86_64 and arm64. For v4, tested on x86_64
again. And on x86_64, the printed messages look like below:
--------------------------------------------------------------
kexec measurement buffer for the loaded kernel at 0x207fffe000.
Loaded purgatory at 0x207fff9000
Loaded boot_param, command line and misc at 0x207fff3000 bufsz=0x1180 memsz=0x1180
Loaded 64bit kernel at 0x207c000000 bufsz=0xc88200 memsz=0x3c4a000
Loaded initrd at 0x2079e79000 bufsz=0x2186280 memsz=0x2186280
Final command line is: root=/dev/mapper/fedora_intel--knightslanding--lb--02-root ro
rd.lvm.lv=fedora_intel-knightslanding-lb-02/root console=ttyS0,115200N81 crashkernel=256M
E820 memmap:
0000000000000000-000000000009a3ff (1)
000000000009a400-000000000009ffff (2)
00000000000e0000-00000000000fffff (2)
0000000000100000-000000006ff83fff (1)
000000006ff84000-000000007ac50fff (2)
......
000000207fff6150-000000207fff615f (128)
000000207fff6160-000000207fff714f (1)
000000207fff7150-000000207fff715f (128)
000000207fff7160-000000207fff814f (1)
000000207fff8150-000000207fff815f (128)
000000207fff8160-000000207fffffff (1)
nr_segments = 5
segment[0]: buf=0x000000004e5ece74 bufsz=0x211 mem=0x207fffe000 memsz=0x1000
segment[1]: buf=0x000000009e871498 bufsz=0x4000 mem=0x207fff9000 memsz=0x5000
segment[2]: buf=0x00000000d879f1fe bufsz=0x1180 mem=0x207fff3000 memsz=0x2000
segment[3]: buf=0x000000001101cd86 bufsz=0xc88200 mem=0x207c000000 memsz=0x3c4a000
segment[4]: buf=0x00000000c6e38ac7 bufsz=0x2186280 mem=0x2079e79000 memsz=0x2187000
kexec_file_load: type:0, start:0x207fff91a0 head:0x109e004002 flags:0x8
---------------------------------------------------------------------------
This patch (of 7):
When specifying 'kexec -c -d', kexec_load interface will print loading
information, e.g the regions where kernel/initrd/purgatory/cmdline are
put, the memmap passed to 2nd kernel taken as system RAM ranges, and
printing all contents of struct kexec_segment, etc. These are very
helpful for analyzing or positioning what's happening when kexec/kdump
itself failed. The debugging printing for kexec_load interface is made in
user space utility kexec-tools.
Whereas, with kexec_file_load interface, 'kexec -s -d' print nothing.
Because kexec_file code is mostly implemented in kernel space, and the
debugging printing functionality is missed. It's not convenient when
debugging kexec/kdump loading and jumping with kexec_file_load interface.
Now add KEXEC_FILE_DEBUG to kexec_file flag to control the debugging
message printing. And add global variable kexec_file_dbg_print and macro
kexec_dprintk() to facilitate the printing.
This is a preparation, later kexec_dprintk() will be used to replace the
existing pr_debug(). Once 'kexec -s -d' is specified, it will print out
kexec/kdump loading information. If '-d' is not specified, it regresses
to pr_debug().
Link: https://lkml.kernel.org/r/20231213055747.61826-1-bhe@redhat.com
Link: https://lkml.kernel.org/r/20231213055747.61826-2-bhe@redhat.com
Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: Conor Dooley <conor@kernel.org>
Cc: Joe Perches <joe@perches.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-12-13 05:57:41 +00:00
|
|
|
|
2025-04-21 22:25:09 +00:00
|
|
|
extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size);
|
|
|
|
|
extern void kimage_unmap_segment(void *buffer);
|
2015-09-09 22:38:55 +00:00
|
|
|
#else /* !CONFIG_KEXEC_CORE */
|
2005-06-25 21:58:26 +00:00
|
|
|
struct pt_regs;
|
|
|
|
|
struct task_struct;
|
2025-04-21 22:25:09 +00:00
|
|
|
struct kimage;
|
2015-12-14 10:19:11 +00:00
|
|
|
static inline void __crash_kexec(struct pt_regs *regs) { }
|
2005-06-25 21:58:26 +00:00
|
|
|
static inline void crash_kexec(struct pt_regs *regs) { }
|
|
|
|
|
static inline int kexec_should_crash(struct task_struct *p) { return 0; }
|
2016-08-02 21:06:16 +00:00
|
|
|
static inline int kexec_crash_loaded(void) { return 0; }
|
2025-04-21 22:25:09 +00:00
|
|
|
static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size)
|
|
|
|
|
{ return NULL; }
|
|
|
|
|
static inline void kimage_unmap_segment(void *buffer) { }
|
2015-08-01 23:08:06 +00:00
|
|
|
#define kexec_in_progress false
|
2015-09-09 22:38:55 +00:00
|
|
|
#endif /* CONFIG_KEXEC_CORE */
|
2015-02-17 21:45:56 +00:00
|
|
|
|
2022-07-13 07:21:11 +00:00
|
|
|
#ifdef CONFIG_KEXEC_SIG
|
|
|
|
|
void set_kexec_sig_enforced(void);
|
|
|
|
|
#else
|
|
|
|
|
static inline void set_kexec_sig_enforced(void) {}
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-02-17 21:45:56 +00:00
|
|
|
#endif /* !defined(__ASSEBMLY__) */
|
|
|
|
|
|
2005-06-25 21:57:52 +00:00
|
|
|
#endif /* LINUX_KEXEC_H */
|
