linux-stable.git/kernel/kexec_file.c, branch v4.14.331

kexec_file: drop weak attribute from arch_kexec_apply_relocations[_add]

2022-07-02T14:18:11+00:00

commit 3e35142ef99fe6b4fe5d834ad43ee13cca10a2dc upstream.

Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
symbols") [1], binutils (v2.36+) started dropping section symbols that
it thought were unused.  This isn't an issue in general, but with
kexec_file.c, gcc is placing kexec_arch_apply_relocations[_add] into a
separate .text.unlikely section and the section symbol ".text.unlikely"
is being dropped. Due to this, recordmcount is unable to find a non-weak
symbol in .text.unlikely to generate a relocation record against.

Address this by dropping the weak attribute from these functions.
Instead, follow the existing pattern of having architectures #define the
name of the function they want to override in their headers.

[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1

[akpm@linux-foundation.org: arch/s390/include/asm/kexec.h needs linux/module.h]
Link: https://lkml.kernel.org/r/20220519091237.676736-1-naveen.n.rao@linux.vnet.ibm.com
Signed-off-by: Michael Ellerman 
Signed-off-by: Naveen N. Rao 
Cc: "Eric W. Biederman" 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

kernel: kexec_file: fix error return code of kexec_calculate_store_digests()

2021-05-22T08:57:39+00:00

[ Upstream commit 31d82c2c787d5cf65fedd35ebbc0c1bd95c1a679 ]

When vzalloc() returns NULL to sha_regions, no error return code of
kexec_calculate_store_digests() is assigned.  To fix this bug, ret is
assigned with -ENOMEM in this case.

Link: https://lkml.kernel.org/r/20210309083904.24321-1-baijiaju1990@gmail.com
Fixes: a43cac0d9dc2 ("kexec: split kexec_file syscall code to kexec_file.c")
Signed-off-by: Jia-Ju Bai 
Reported-by: TOTE Robot 
Acked-by: Baoquan He 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

ima: Free IMA measurement buffer after kexec syscall

2021-03-03T17:22:43+00:00

[ Upstream commit f31e3386a4e92ba6eda7328cb508462956c94c64 ]

IMA allocates kernel virtual memory to carry forward the measurement
list, from the current kernel to the next kernel on kexec system call,
in ima_add_kexec_buffer() function.  This buffer is not freed before
completing the kexec system call resulting in memory leak.

Add ima_buffer field in "struct kimage" to store the virtual address
of the buffer allocated for the IMA measurement list.
Free the memory allocated for the IMA measurement list in
kimage_file_post_load_cleanup() function.

Signed-off-by: Lakshmi Ramasubramanian 
Suggested-by: Tyler Hicks 
Reviewed-by: Thiago Jung Bauermann 
Reviewed-by: Tyler Hicks 
Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

kexec_file: adjust declaration of kexec_purgatory

2017-07-12T23:26:02+00:00

Defining kexec_purgatory as a zero-length char array upsets compile time
size checking.  Since this is built on a per-arch basis, define it as an
unsized char array (like is done for other similar things, e.g.  linker
sections).  This silences the warning generated by the future
CONFIG_FORTIFY_SOURCE, which did not like the memcmp() of a "0 byte"
array.  This drops the __weak and uses an extern instead, since both
users define kexec_purgatory.

Link: http://lkml.kernel.org/r/1497903987-21002-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook 
Acked-by: "Eric W. Biederman" 
Cc: Daniel Micay 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kdump: protect vmcoreinfo data under the crash memory

2017-07-12T23:26:00+00:00

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 
Tested-by: Michael Holzheu 
Cc: Benjamin Herrenschmidt 
Cc: Dave Young 
Cc: Eric Biederman 
Cc: Hari Bathini 
Cc: Juergen Gross 
Cc: Mahesh Salgaonkar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kimage_file_prepare_segments(): don't open-code memdup_user()

2017-06-30T06:04:10+00:00

Signed-off-by: Al Viro

kexec, x86/purgatory: Unbreak it and clean it up

2017-03-10T19:55:09+00:00

The purgatory code defines global variables which are referenced via a
symbol lookup in the kexec code (core and arch).

A recent commit addressing sparse warnings made these static and thereby
broke kexec_file.

Why did this happen? Simply because the whole machinery is undocumented and
lacks any form of forward declarations. The variable names are unspecific
and lack a prefix, so adding forward declarations creates shadow variables
in the core code. Aside of that the code relies on magic constants and
duplicate struct definitions with no way to ensure that these things stay
in sync. The section placement of the purgatory variables happened by
chance and not by design.

Unbreak kexec and cleanup the mess:

 - Add proper forward declarations and document the usage
 - Use common struct definition
 - Use the proper common defines instead of magic constants
 - Add a purgatory_ prefix to have a proper name space
 - Use ARRAY_SIZE() instead of a homebrewn reimplementation
 - Add proper sections to the purgatory variables [ From Mike ]

Fixes: 72042a8c7b01 ("x86/purgatory: Make functions and variables static")
Reported-by: Mike Galbraith <
Signed-off-by: Thomas Gleixner 
Cc: Nicholas Mc Guire 
Cc: Borislav Petkov 
Cc: Vivek Goyal 
Cc: "Tobin C. Harding" 
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1703101315140.3681@nanos
Signed-off-by: Thomas Gleixner

ima: on soft reboot, save the measurement list

2016-12-20T17:48:44+00:00

The TPM PCRs are only reset on a hard reboot.  In order to validate a
TPM's quote after a soft reboot (eg.  kexec -e), the IMA measurement
list of the running kernel must be saved and restored on boot.

This patch uses the kexec buffer passing mechanism to pass the
serialized IMA binary_runtime_measurements to the next kernel.

Link: http://lkml.kernel.org/r/1480554346-29071-7-git-send-email-zohar@linux.vnet.ibm.com
Signed-off-by: Thiago Jung Bauermann 
Signed-off-by: Mimi Zohar 
Acked-by: "Eric W. Biederman" 
Acked-by: Dmitry Kasatkin 
Cc: Andreas Steffen 
Cc: Josh Sklar 
Cc: Dave Young 
Cc: Vivek Goyal 
Cc: Baoquan He 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Stewart Smith 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

2016-11-30T12:15:01+00:00

kexec_locate_mem_hole will be used by the PowerPC kexec_file_load
implementation to find free memory for the purgatory stack.

Signed-off-by: Thiago Jung Bauermann 
Acked-by: Dave Young 
Signed-off-by: Michael Ellerman

kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

2016-11-30T12:14:59+00:00

This is done to simplify the kexec_add_buffer argument list.
Adapt all callers to set up a kexec_buf to pass to kexec_add_buffer.

In addition, change the type of kexec_buf.buffer from char * to void *.
There is no particular reason for it to be a char *, and the change
allows us to get rid of 3 existing casts to char * in the code.

Signed-off-by: Thiago Jung Bauermann 
Acked-by: Dave Young 
Acked-by: Balbir Singh 
Signed-off-by: Michael Ellerman