Signed-off-by: Simon Horman <horms@kernel.org>

When the kernel is built relocatable, the starting address can be
anything above 1Mb on x86. However, the startup_*() entries consider
that the minumum address for the kernel for the decompression has to
be at least LOAD_PHYSICAL_ADDR which is turn the value that is provided
as pref_address in boot protocol. The boot protocol itself says:

  This field, if nonzero, represents a preferred load address for the
  kernel.  A relocating bootloader should attempt to load at this
  address if possible.

Besides that the code in the kernel (arch/x86/kernel/kexec-bzimage64.c)
has these lines (in bzImage64_load() function):

    if (header->pref_address < MIN_KERNEL_LOAD_ADDR)
        kbuf.buf_min = MIN_KERNEL_LOAD_ADDR;
    else
        kbuf.buf_min = header->pref_address;

All that said, do the same in kexec tools. Without this patch
the relocatable kernel may end up in the memory hole that is
not enough for in-place decompression and Bad Things will happen
as it's proven on Intel Merrifield, that has a reserved memory
block starting at 64Mb.

Note, it doesn't mean that kernel has no issues itself in this particular
stage, but at least we may work around some corner cases for kexec.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Simon Horman <horms@kernel.org>

If the region of the memory is not enough for the decompressed
kernel, e.g., it follows by reserved memory, Bad Things may happen
as it's proven to be in practice on Intel Merrifield platform.

Include decompressed kernel size into the calculations for finding
the appropriate hole in memory to load kernel to.

Note, this has been already done for 64-bit case, this just
synchronises the approach for 32-bit case.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Simon Horman <horms@kernel.org>

There is a fd leakage in the fail path when writing to initrd fd in
uki_image_probe(). Fix it by this patch.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@kernel.org>

When kexec_iomem_for_each_line() reads from /proc/iomem,
concurrent modifications to /proc/iomem may lead to
usablemem_rgns recording duplicate Crash kernel segments.
This can result in the number of retrieved Crash kernel
segments exceeding CRASH_MAX_RESERVED_RANGES, triggering
a realloc of the crash_reserved_mem in usablemem_rgns,
which could crash the process. We should ensure that each
range added to usablemem_rgns is unique to prevent these issues.

Reviewed-by: Louhongxiang <louhongxiang@huawei.com>
Reviewed-by: wangbin <wangbin224@huawei.com>
Reviewed-by: yangyanchao <yangyanchao6@huawei.com>
Signed-off-by: chenhaixiang <chenhaixiang3@huawei.com>
Signed-off-by: Simon Horman <horms@kernel.org>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@kernel.org>

A UKI image is a PE file that consists of several sections, typically
including: .text, .data, .linux, .initrd, .cmdline, and others.

The kernel image is stored in the .linux section, which is one of the
formats currently recognized by kexec-tools. Therefore, the UKI parser
can be used to strip away the UKI layer, allowing the other parser to
continue the procession of the kernel image.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@kernel.org>

At present, initrd information is passed through --initrd args, and
handled until image load. But for the UKI case, the initrd may be stored
implicitly in the .initrd section.

It means that initrd is perceived at the probe stage. And there should
be a way to carry this information forward to the load stage. In oder to
implement that, introducing a global implicit_initrd_fd.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@kernel.org>

Running bootstrap on Debian spills a few problems in configure.ac.
Update it accordingly.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Simon Horman <horms@kernel.org>

Compiler is not happy when wrong specifier is being used.
Fix them all.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Simon Horman <horms@kernel.org>

Compiler is not happy when wrong specifier is being used.
Fix them all.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Simon Horman <horms@kernel.org>

32-bit compilation makes compiler unhappy about too big right shifts.
Use a similar trick to Linux kernel project by replacing foo >> 32 by
(foo >> 16) >> 16.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Simon Horman <horms@kernel.org>

Commit b84fcdd4 [1] introduced a usage of PATH_MAX in file
"kexec-s390.c". This constant is defined in the <limits.h> header.
See [2].

With some libc, such as musl, kexec-tools fails to build with output:

    kexec/arch/s390/kexec-s390.c: In function 'remove_offline_memory':
    kexec/arch/s390/kexec-s390.c:120:19: error: 'PATH_MAX' undeclared (first use in this function)
      120 |         char path[PATH_MAX];
          |                   ^~~~~~~~

The issue can be reproduced, for example, with Buildroot Linux, using
a s390 gcc toolchain with the musl libc and the following commands:

    git clone -b 2024.05.1 --depth 1 https://gitlab.com/buildroot.org/buildroot.git
    cd buildroot
    cat > .config <<EOF
    BR2_s390x=y
    BR2_TOOLCHAIN_BUILDROOT_MUSL=y
    BR2_PACKAGE_KEXEC=y
    EOF
    make olddefconfig
    make

Note: in this test, kexec-tools v2.0.28 is used.

This commit fixes the issue by adding the missing header inclusion.

[1] https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=b84fcdd48cbe70e54e66f2cf1b251e0db58f04f4
[2] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html



Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Simon Horman <horms@kernel.org>

Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.

Signed-off-by: Simon Horman <horms@kernel.org>

Signed-off-by: Simon Horman <horms@kernel.org>

Signed-off-by: Simon Horman <horms@kernel.org>

Update the man page and --help option to make the description of the
--hotplug option easier to understand.

Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Simon Horman <horms@kernel.org>

Kernel commits b741092d5976 ("powerpc/crash: add crash CPU hotplug
support") and 849599b702ef ("powerpc/crash: add crash memory hotplug
support") added crash CPU/Memory hotplug support on PowerPC. This patch
extends that support for the kexec_load syscall.

During CPU/Memory hotplug events on PowerPC, two kexec segments,
elfcorehdr, and FDT, get updated by the kernel. To ensure the kernel
can safely update these two kexec segments for the kdump image loaded
using the kexec_load system call, the following changes are made:

1. Extra size is allocated for both elfcorehdr and FDT to accommodate
   additional resources in the future. For the elfcorehdr, the size hint
   is taken from /sys/kernel/crash_elfcorehdr_size sysfs, while for FDT,
   extra size is allocated to hold possible CPU nodes.

2. Both elfcorehdr and FDT are skipped from SHA calculation.

Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Simon Horman <horms@kernel.org>

Kernel commit 79365026f869 (crash: add a new kexec flag for hotplug
support) has introduced a new kexec flag to generalize hotplug support.
The newly introduced kexec flags for hotplug allow architectures to
exclude all the required kexec segments from SHA calculation so that
the kernel can update them on hotplug events. This was not possible
earlier with the KEXEC_UPDATE_ELFCOREHDR kexec flags since it was added
only for the elfcorehdr segment.

To enable architectures to control the list of kexec segments to exclude
when hotplug support is enabled, add a new architecture-specific
function named arch_do_exclude_segment. During the SHA calculation, this
function gets called to let the architecture decide whether a specific
kexec segment should be considered for SHA calculation or not.

Note: To avoid breaking backward compatibility, the new kexec flag
KEXEC_CRASH_HOTPLUG_SUPPORT is not used for x86 for now.

Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@kernel.org>

Musl C library only supports POSIX basename function. while glibc has
both GNU extention as well as POSIX basename implemented. Switch to
using posix version, so it can work across musl and glibc

basename prototype has been removed from string.h from latest musl [1]
compilers e.g. clang-18/GCC-14 flags the absense of prototype as error.
therefore include libgen.h for providing it.

[1] https://git.musl-libc.org/cgit/musl/commit/?id=725e17ed6dff4d0cd22487bb64470881e86a92e7



Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Simon Horman <horms@kernel.org>

When kernel cmdline reserved multiple crash kernel segments, like:
"crashkernel=4G,high crashkernel=256M,low".
Cmdline segment may be loaded in locations larger than 4G of memory.
So the parameter 'buf_max' of add_buffer function should be
'hole_max'.

Signed-off-by: Hongchen Zhang <zhanghongchen@loongson.cn>
Signed-off-by: Ming Wang <wangming01@loongson.cn>
Signed-off-by: Simon Horman <horms@kernel.org>

Production kernel may reserved multiple crash kernel segments, like:
'crashkernel=4G,high crashkernel=256M,low'.
So we should pass multiple mem=<size>@<address> parameters in capture kernel.

Signed-off-by: Hongchen Zhang <zhanghongchen@loongson.cn>
Signed-off-by: Ming Wang <wangming01@loongson.cn>
Signed-off-by: Simon Horman <horms@kernel.org>

Use kernel_size instead of kernel image size is wrong, we should get
the kernel image size from loongarch image header.

Signed-off-by: Ming Wang <wangming01@loongson.cn>
Signed-off-by: Hongchen Zhang <zhanghongchen@loongson.cn>
Signed-off-by: Simon Horman <horms@kernel.org>

When "CONFIG_ARM_LPAE" is enabled,3 level page table
is used by MMU, the "SECTION_SIZE" is defined with
(1 << 21), but 'add_buffer_phys_virt()' hardcode this
to (1 << 20).

Suggested-By:  <fredrik.markstrom@gmail.com>
Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Simon Horman <horms@kernel.org>

As detected by rpmlint,
    kexec-tools.x86_64: E: incorrect-fsf-address /usr/share/licenses/kexec-tools/COPYING
    The Free Software Foundation address in this file seems to be outdated or
    misspelled. Ask upstream to update the address, or if this is a license file,
    possibly the entire file with a new copy available from the FSF.

Replace current one with
https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt


to fix this issue.

Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Simon Horman <horms@kernel.org>

There's a incorrect array operation in function scan_vmcoreinfo(), it
will cause below warning message.

-----------------------
util_lib/elf_info.c: In function ‘scan_vmcoreinfo’:
util_lib/elf_info.c:360:43: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  360 |                         temp_buf[len + 1] = '\0';
      |                         ~~~~~~~~~~~~~~~~~~^~~~~~
util_lib/elf_info.c:319:14: note: at offset 1024 into destination object ‘temp_buf’ of size 1024
  319 |         char temp_buf[1024];
      |              ^~~~~~~~
---------------------

Fix it to avoid oob access of array.

Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@kernel.org>

This add KEXEC_FILE_DEBUG to kexec_file_flags so that it can be passed
to kernel when '-d' is added with kexec_file_load interface. With that
flag enabled, kernel can enable the debugging message printing.

Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@kernel.org>

Update to use checkout@v4.

This addresses the following warning that appears in GitHub runs:

"Node.js 16 actions are deprecated. Please update the following actions
 to use Node.js 20: actions/checkout@v3. For more information
 see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Link: https://github.com/horms/kexec-tools/actions/runs/7753454923


Signed-off-by: Simon Horman <horms@kernel.org>

Newer versions of the GNU assembler (observed with binutils 2.41) will
complain about the ".arch i386" in files assembled with "as --64",
with the message "Error: 64bit mode not supported on 'i386'".

Fix by moving ".arch i386" below the relevant ".code32" directive, so
that the assembler is no longer expecting 64-bit instructions to be used
by the time that the ".arch i386" directive is encountered.

Based on similar iPXE fix:
https://github.com/ipxe/ipxe/commit/6ca597eee



Signed-off-by: Michel Lind <michel@michel-slm.name>
Signed-off-by: Simon Horman <horms@kernel.org>

Since commit 29fe5067 ("kexec: make -a the default")
kexec tries the kexec_file_load syscall first and only falls back to kexec_load on
selected error codes.

This effectively breaks kexec on XEN, unless -c is pecified to force the kexec_load
syscall.

The XEN-specific functions (xen_kexec_load / xen_kexec_unload) are only called
from my_load / k_unload, i.e. the kexec_load code path.

With -p (panic kernel) kexec_file_load on XEN fails with -EADDRNOTAVAIL (crash
kernel reservation is ignored by the kernel on XEN), which is not in the list
of return codes that cause the fallback to kexec_file.

Without -p kexec_file_load actualy leads to a kernel oops on v6.4.0
(needs to be dubugged separately).

Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Fixes: 29fe5067 ("kexec: make -a the default")
Signed-off-by: Simon Horman <horms@kernel.org>

Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.

Signed-off-by: Simon Horman <horms@kernel.org>

Signed-off-by: Simon Horman <horms@kernel.org>

Signed-off-by: Simon Horman <horms@kernel.org>

Currently, kexec loads vmlinux.efi to address 0 instead of the link
address. This causes kexec to fail to boot the new vmlinux.efi on qemu.

  pei_loongarch_load: kernel_segment: 0000000000000000
  pei_loongarch_load: kernel_entry:   00000000013f1000
  pei_loongarch_load: image_size:     0000000001ca0000
  pei_loongarch_load: text_offset:    0000000000200000
  pei_loongarch_load: phys_offset:    0000000000000000
  pei_loongarch_load: PE format:      yes
  loongarch_load_other_segments:333: command_line: kexec console=ttyS0,115200
  kexec_load: entry = 0x13f1000 flags = 0x1020000
  nr_segments = 2
  segment[0].buf   = 0x7fffeea38010
  segment[0].bufsz = 0x1b55200
  segment[0].mem   = (nil)
  segment[0].memsz = 0x1ca0000
  segment[1].buf   = 0x5555570940b0
  segment[1].bufsz = 0x200
  segment[1].mem   = 0x1ca0000
  segment[1].memsz = 0x4000

This patch constrains the range of the kernel segment by `hole_min`
and `hole_max` to place vmlinux.efi exactly at the link address.

  pei_loongarch_load: kernel_segment: 0000000000200000
  pei_loongarch_load: kernel_entry:   00000000013f1000
  pei_loongarch_load: image_size:     0000000001ca0000
  pei_loongarch_load: text_offset:    0000000000200000
  pei_loongarch_load: phys_offset:    0000000000000000
  pei_loongarch_load: PE format:      yes
  loongarch_load_other_segments:339: command_line: kexec console=ttyS0,115200
  kexec_load: entry = 0x13f1000 flags = 0x1020000
  nr_segments = 2
  segment[0].buf   = 0x7ffff2028010
  segment[0].bufsz = 0x1b55200
  segment[0].mem   = 0x200000
  segment[0].memsz = 0x1ca0000
  segment[1].buf   = 0x555557498098
  segment[1].bufsz = 0x200
  segment[1].mem   = 0x1ea0000
  segment[1].memsz = 0x4000

Signed-off-by: WANG Rui <wangrui@loongson.cn>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Simon Horman <horms@kernel.org>

Normally vmlinux for LoongArch is of ET_EXEC type, while if built with
CONFIG_RELOCATABLE (this is PIE) and Clang, it will be of ET_DYN type.
Meanwhile, physical address field of segments in vmlinux has actually
the same value as virtual address field.

Similar to arm64, this patch allows to unconditionally skip the check
on LoongArch.

Link: https://github.com/ClangBuiltLinux/linux/issues/1963


Signed-off-by: WANG Rui <wangrui@loongson.cn>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Simon Horman <horms@kernel.org>

With uclibc, getrandom() is only defined with _GNU_SOURCE, fix that:

kexec/arch/m68k/bootinfo.c: In function 'bootinfo_add_rng_seed':
kexec/arch/m68k/bootinfo.c:231:13: warning: implicit declaration of function 'getrandom'; did you mean 'srandom'? [-Wimplicit-function-declaration]
  231 |         if (getrandom(bi->rng_seed.data, RNG_SEED_LEN, GRND_NONBLOCK) != RNG_SEED_LEN) {
      |             ^~~~~~~~~
      |             srandom
kexec/arch/m68k/bootinfo.c:231:56: error: 'GRND_NONBLOCK' undeclared (first use in this function)
  231 |         if (getrandom(bi->rng_seed.data, RNG_SEED_LEN, GRND_NONBLOCK) != RNG_SEED_LEN) {
      |                                                        ^~~~~~~~~~~~~

Fixes:  b9de0518 ("m68k: pass rng seed via BI_RNG_SEED")
Cc: Jason@zx2c4.com
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Simon Horman <horms@kernel.org>

The kexec cannot load LZMA compressed vmlinuz.efi on LoongArch.

  Try LZMA decompression.
  lzma_decompress_file: read on /tmp/Image4yyfhM of 65536 bytes failed
  pez_prepare: decompressed size 8563960
  pez_prepare: done
  Cannot load vmlinuz.efi

The root cause is that lzma decompressor requires more memory usage,
which exceeds the current 64M limit.

Reported-by: Huacai Chen <chenhuacai@kernel.org>
Signed-off-by: WANG Rui <wangrui@loongson.cn>
Signed-off-by: Simon Horman <horms@kernel.org>

Currently 'kexec --help' on powerpc64 prints the generic help/usage to
stdout, and the powerpc64 specific options to stderr

That is, if the stdout of 'kexec --help' is redirected to some file,
some of the help options will not be redirected, and instead printed on
the terminal/stderr:

    [root@machine kexec-tools]# kexec --help > /tmp/out
         --command-line=<Command line> command line to append.
         --append=<Command line> same as --command-line.
         --ramdisk=<filename> Initial RAM disk.
         --initrd=<filename> same as --ramdisk.
         --devicetreeblob=<filename> Specify device tree blob file.
                                     Not applicable while using
    --kexec-file-syscall.
         --dtb=<filename> same as --devicetreeblob.
    elf support is still broken
         --elf64-core-headers Prepare core headers in ELF64 format
         --dt-no-old-root Do not reuse old kernel root= param.
                          while creating flatten device tree.

Fix this inconsistency by writing powerpc64 specific options to stdout,
similar to the generic 'kexec --help'

With the proposed changes, it is like this (nothing printed to stderr):

    [root@machine kexec-tools]# ./build/sbin/kexec --help > /tmp/out

Reported-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Signed-off-by: Simon Horman <horms@kernel.org>

Bump workflow to use latest LTS release.

Signed-off-by: Simon Horman <horms@kernel.org>

The Makefile omits the iomem.h file, causing the archive file
generated by 'make dist' to lose iomem.h. This patch is used to
fix this problem.

Signed-off-by: Ming Wang <wangming01@loongson.cn>
Signed-off-by: Simon Horman <horms@kernel.org>