summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-03arm64: kdump: deal with a lot of resource entries in /proc/iomemAKASHI Takahiro
As described in the commit ("arm64: kexec: allocate memory space avoiding reserved regions"), /proc/iomem now has a lot of "reserved" entries, and it's not just enough to have a fixed size of memory range array. With this patch, kdump is allowed to handle arbitrary number of memory ranges, using mem_regions_alloc_and_xxx() functions. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: Bhupesh Sharma <bhsharma@redhat.com> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-01-03arm64: kexec: allocate memory space avoiding reserved regionsAKASHI Takahiro
On UEFI/ACPI-only system, some memory regions, including but not limited to UEFI memory map and ACPI tables, must be preserved across kexec'ing. Otherwise, they can be corrupted and result in early failure in booting a new kernel. In recent kernels, /proc/iomem now has an extended file format like: 40000000-5871ffff : System RAM 41800000-426affff : Kernel code 426b0000-42aaffff : reserved 42ab0000-42c64fff : Kernel data 54400000-583fffff : Crash kernel 58590000-585effff : reserved 58700000-5871ffff : reserved 58720000-58b5ffff : reserved 58b60000-5be3ffff : System RAM 58b61000-58b61fff : reserved where the "reserved" entries at the top level or under System RAM (and its descendant resources) are ones of such kind and should not be regarded as usable memory ranges where several free spaces for loading kexec data will be allocated. With this patch, get_memory_ranges() will handle this format of file correctly. Note that, for safety, unknown regions, in addition to "reserved" ones, will also be excluded. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: Bhupesh Sharma <bhsharma@redhat.com> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-01-03kexec: add variant helper functions for handling memory regionsAKASHI Takahiro
mem_regions_alloc_and_add() and mem_regions_alloc_and_exclude() are functionally equivalent to, respectively, mem_regions_add() and mem_regions_exclude() except the formers will re-allocate memory dynamically when no more entries are available in 'ranges' array. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: Bhupesh Sharma <bhsharma@redhat.com> Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-10-07kexec-tools: Fix conversion overflow when compiling on 32-bit platformsHelge Deller
When compiling kexec-tools on a 32-bit platform, assigning an (unsigned long long) value to an (unsigned long) variable creates this warning: elf_info.c: In function 'read_phys_offset_elf_kcore': elf_info.c:805:14: warning: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '18446744073709551615' to '4294967295' 805 | *phys_off = UINT64_MAX; Fix it by using ULONG_MAX instead of UINT64_MAX. Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-10-03kexec-tools: Fix possible out-of-bounds access in ifdownHelge Deller
Fix a possible out-of-bounds access in function ifdown(): ifdown.c: In function 'ifdown': ifdown.c:56:4: warning: 'strncpy' specified bound 16 equals destination size [-Wstringop-truncation] 56 | strncpy(ifr.ifr_name, ifp->if_name, IFNAMSIZ); Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-10-01kexec: add support for PARISC architectureSven Schnelle
This patch adds support for the parisc Architecture. kexec support for parisc is included with linux-5.4. Signed-off-by: Sven Schnelle <svens@stackframe.org> Tested-by: Helge Deller <deller@gmx.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-16kexec/arm: undefine __NR_kexec_file_load for armQuanyang Wang
In the kernel upstream commit 4ab65ba7a5cb ("ARM: add kexec_file_load system call number"), __NR_kexec_file_load for arm has been defined to be 401. This results that even if kexec_file_load isn't implemented for arm but the function is_kexec_file_load_implemented() will still return true. So undef __NR_kexec_file_load for arm architecture. Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-16i386/kexec-mb2-x86.c: Fix compilation warningBhupesh Sharma
This patch fixes the following compilation warning in 'i386/kexec-mb2-x86.c' regarding the variable 'result' which is set but not used: kexec/arch/i386/kexec-mb2-x86.c:402:6: warning: variable ‘result’ set but not used [-Wunused-but-set-variable] int result; ^~~~~~ Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-16vmcore-dmesg/vmcore-dmesg.c: Fix shifting error reported by cppcheckBhupesh Sharma
Running 'cppcheck' static code analyzer (see cppcheck(1)) on 'vmcore-dmesg/vmcore-dmesg.c' shows the following shifting error: $ cppcheck --enable=all vmcore-dmesg/vmcore-dmesg.c Checking vmcore-dmesg/vmcore-dmesg.c ... [vmcore-dmesg/vmcore-dmesg.c:17]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour Fix the same via this patch. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-08Limit the size of vmcore-dmesg.txt to 2GLianbo Jiang
With some corrupted vmcore files, the vmcore-dmesg.txt file may grow forever till the kdump disk becomes full, and also probably causes the disk error messages as follow: ... sd 0:0:0:0: [sda] tag#6 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#6 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00 blk_update_request: I/O error, dev sda, sector 134630552 sd 0:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#7 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00 blk_update_request: I/O error, dev sda, sector 134630552 ... If vmcore-dmesg.txt occupies the whole disk, the vmcore can not be saved, this is also a problem. Lets limit the size of vmcore-dmesg.txt to avoid such problems. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-08Cleanup: move it back from util_lib/elf_info.cLianbo Jiang
Some code related to vmcore-dmesg.c is put into the util_lib, which is not very reasonable, so lets move it back and tidy up those code. In addition, that will also help to limit the size of vmcore-dmesg.txt in vmcore-dmesg.c instead of elf_info.c. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-08Fix an error definition about the variable 'fname'Lianbo Jiang
The variable 'fname' is mistakenly defined two twice, the first definition is in the vmcore-dmesg.c, and the second definition is in the elf_info.c. That is confused and incorrect although it's a static type, because the value of variable 'fname' is not assigned(set) in elf_info.c. Anyway, its value will be always 'null' when printing an error information. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-08Cleanup: remove the read_elf_kcore()Lianbo Jiang
Here, no need to wrap the read_elf() again, lets invoke it directly. So remove the read_elf_kcore() and clean up redundant code. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-03x86: Fix PAGE_OFFSET for kernels since 4.20Donald Buczek
Linux kernel commit d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging") changed the base of the direct mapping from 0xffff880000000000 to 0xffff888000000000. This was merged into v4.20-rc2. Update to new address accordingly. Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-03kexec-tools 2.0.20.gitSimon Horman
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@verge.net.au>
2019-07-25kexec-tools 2.0.20Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec-tools 2.0.20-rc2Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec/arm64: Add support for handling zlib compressed (Image.gz) imageBhupesh Sharma
Currently the kexec_file_load() support for arm64 doesn't allow handling zlib compressed (i.e. Image.gz) image. Since most distributions use 'make zinstall' rule inside 'arch/arm64/boot/Makefile' to install the arm64 Image.gz compressed file inside the boot destination directory (for e.g. /boot), currently we cannot use kexec_file_load() to load vmlinuz (or Image.gz): # file /boot/vmlinuz /boot/vmlinuz: gzip compressed data, was "Image", <..snip..>, max compression, from Unix, original size 21945120 Now, since via kexec_file_load() we pass the 'fd' of Image.gz (compressed file) via the following command line ... # kexec -s -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline ... kernel returns -EINVAL error value, as it is not able to locate the magic number =0x644d5241, which is expected in the 64-byte header of the decompressed kernel image. We can fix this in user-space kexec-tools, which handles an 'Image.gz' being passed via kexec_file_load(), using an approach as follows: a). Copy the contents of Image.gz to a temporary file. b). Decompress (gunzip-decompress) the contents inside the temporary file. c). Pass the 'fd' of the temporary file to the kernel space. So basically the kernel space still gets a decompressed kernel image to load via kexec-tools I tested this patch for the following three use-cases: 1. Uncompressed Image file: #kexec -s -l Image --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline 2. Signed Image file: #kexec -s -l Image.signed --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline 3. zlib compressed Image.gz file: #kexec -s -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec/kexec-zlib.h: Add 'is_zlib_file()' helper functionBhupesh Sharma
This patch adds 'is_zlib_file()' helper function which can be used to quickly determine with the passed kernel image is a zlib compressed kernel image. This is specifically useful for arm64 zImage (or Image.gz) support, which is introduced by later patches in this patchset. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec-uImage-arm64.c: Fix return value of uImage_arm64_probe()Bhupesh Sharma
Commit bf06cf2095e1 ("kexec/uImage: probe to identify a corrupted image"), defined the 'uImage_probe_kernel()' function return values and correspondingly ;uImage_arm64_probe()' returns the same (0 -> If the image is valid 'type' image, -1 -> If the image is corrupted and 1 -> If the image is not a uImage). This causes issues because, in later patches we introduce zImage support for arm64, and since it is probed after uImage, the return values from 'uImage_arm64_probe()' needs to be fixed to make sure that kexec will not return with an invalid error code. Now, 'uImage_arm64_probe()' returns the following values instead: 0 - valid uImage. -1 - uImage is corrupted. 1 - image is not a uImage. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec/kexec.c: Add the missing close() for fd used for kexec_file_load()Bhupesh Sharma
In kexec/kexec.c, we open() the kernel Image file and pass this file descriptor to the kexec_file_load() system call, but never call a corresponding close(). Fix the same via this patch. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-10kexec-tools 2.0.20-rc1Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-10x86: Include kexec-mb2-x86.c and multiboot2.h in distributionSimon Horman
Fixes: 22a2ed55132e ("x86: Support multiboot2 images") Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-03x86: re-order includes to avoid duplicate struct e820entrySimon Horman
xenctrl.h defines struct e820entry as: if defined(__i386__) || defined(__x86_64__) ... #define E820_RAM 1 ... struct e820entry { uint64_t addr; uint64_t size; uint32_t type; } __attribute__((packed)); ... #endif $ dpkg-query -S /usr/include/xenctrl.h libxen-dev:amd64: /usr/include/xenctrl.h $ dpkg-query -W libxen-dev:amd64 libxen-dev:amd64 4.8.5+shim4.10.2+xsa282-1+deb9u11 ./include/x86/x86-linux.h defines struct e820entry as: #ifndef E820_RAM struct e820entry { uint64_t addr; /* start of memory segment */ uint64_t size; /* size of memory segment */ uint32_t type; /* type of memory segment */ #define E820_RAM 1 ... } __attribute__((packed)); #endif Since cedeee0a3007 ("x86: Introduce helpers for getting RSDP address") ./kexec/arch/i386/kexec-x86-common.c includes +#include "x86-linux-setup.h" #include "../../kexec-xen.h" When xenctrl.h is present the above results in: $ gcc ... In file included from kexec/arch/i386/../../kexec-xen.h:5:0, from kexec/arch/i386/kexec-x86-common.c:43: /usr/include/xenctrl.h:1271:8: error: redefinition of 'struct e820entry' struct e820entry { ^~~~~~~~~ In file included from kexec/arch/i386/x86-linux-setup.h:3:0, from kexec/arch/i386/kexec-x86-common.c:42: ./include/x86/x86-linux.h:16:8: note: originally defined here struct e820entry { ^~~~~~~~~ ... $ gcc --version | head -1 gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 To militate this this problem re-order the includes so that x86-linux.h is included after xenctrl.h and thus struct e820entry will only be defined once due to it being devined conditionally in x86-linux.h. In practice the definitions are the same so it should not matter which is chosen. It also seems rather unpleasent to me to need to play with include ordering. Perhaps a better solution in the longer term would be to rename the local definition of struct e820entry. Fixes: cedeee0a3007 ("x86: Introduce helpers for getting RSDP address") Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-03x86: Support multiboot2 imagesVarad Gautam
Add a new type `multiboot2-x86` that allows loading multiboot2 [1] images within the relocation range specified in the image header. The image is always placed at the lowest available address, regardless of the preference information. [1] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html Signed-off-by: Varad Gautam <vrd@amazon.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-03elf: Support ELF loading with relocationVarad Gautam
Add a helper to allow loading an image within specified address range. This will be used to load multiboot2 images later. Signed-off-by: Varad Gautam <vrd@amazon.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-31crashdump/x86: Use new introduce helper for getting RSDPKairui Song
Use the new introduce helper for getting RSDP, this ensures RSDP is always accessible and avoid code duplication. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-31x86: Always try to fill acpi_rsdp_addr in boot paramsKairui Song
Since kernel commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP address from boot params if available"), kernel accept an acpi_rsdp_addr param in boot_params. So fill in this parameter unconditionally, ensure second kernel always get the right RSDP address consistently, and boot well on EFI system even with EFI service disabled. User no longer need to change the kernel cmdline to workaround the missing RSDP issue. For older version of kernels (Before 5.0), there won't be any change of behavior. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-31x86: Introduce helpers for getting RSDP addressKairui Song
On x86 RSDP is fundamental for booting the machine. When second kernel is incapable of parsing the RSDP address (eg. kexec next kernel on an EFI system with EFI service disabled), kexec should prepare the RSDP address for second kernel. Introduce helpers for getting RSDP from multiple sources, including boot params and EFI firmware. For legacy BIOS interface, there is no better way to find the RSDP address rather than scanning the memory region and search for it, and this will always be done by the kernel as a fallback, so this is no need to try to get the RSDP address for that case. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-31x86: Update boot parameters definationKairui Song
Since kernel commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP address from boot params if available"), kernel accept a acpi_rsdp_addr param in boot_params. Sync the x86_linux_param_header to support this param. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-15x86: Find mounts by FS type, not nameNiklas Hambüchen
The name in mount invocations like mount -t debugfs debugfs /sys/kernel/debug is nothing but convention and cannot be relied upon. For example, https://www.kernel.org/doc/Documentation/filesystems/debugfs.txt recommends making the name "none" instead: mount -t debugfs none /sys/kernel/debug and many existing systems use mounts named "none" or otherwise. Using `mnt_type` instead of `mnt_fsname` allows kexec to work on such systems. This fixes another instance of `poweroff` not working on kexec'ed kernels because the lack of correctly matched mount results in EFI variables not being read and propagated. Signed-off-by: Niklas Hambüchen <mail@nh2.me> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-15x86: Check /proc/mounts before mtab for mountsNiklas Hambüchen
In many situations, especially on read-only file systems and initial ramdisks (intramfs/initrd), /etc/mtab does not exist. Before this commit, kexec would fail to read mounts on such systems in `find_mnt_by_fsname()`, such that `get_bootparam()` would not `boot_params/data`, which would then lead to e.g. `setup_efi_data()` not being called in `setup_efi_info()`. As a result, kexec'ed kernels would not obtain EFI data, subsequentially lack an `ACPI RSDP` entry, emitting: ACPI BIOS Error (bug): A valid RSDP was not found (20180810/tbxfroot-210) and thus fail to turn off the machine on poweroff, instead printing only: reboot: System halted This problem had to be worked around by passing `acpi_rsdp=` manually before. This commit obviates this workaround. See also: * https://github.com/coreos/bugs/issues/167#issuecomment-487320879 * http://lists.infradead.org/pipermail/kexec/2012-October/006924.html Signed-off-by: Niklas Hambüchen <mail@nh2.me> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-15xen: Avoid overlapping segments in low memoryDavid Woodhouse
Unlike Linux which creates a full identity mapping, Xen only maps those segments which are explicitly requested. Therefore, xen_kexec_load() silently adds in a segment from zero to 1MiB to ensure that VGA memory and other things are accessible. However, this doesn't work when there are already segments to be loaded under 1MiB, because the overlap causes Xen to reject the kexec_load. Be more careful and just infill the ranges which are required instead of naïvely adding a full 0-1MiB segment at the end of the list. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-03-06x86: Introduce a new option --reuse-video-typeKairui Song
After commit 060eee58 "x86: use old screen_info if needed", kexec-tools will force use old screen_info and vga type if failed to determine current vga type. But it is not always a good idea. Currently kernel hanging is inspected on some hyper-v VMs after this commit, because hyperv_fb will mimic EFI (or VESA) VGA on first boot up, but after the real driver is loaded, it will switch to new mode and no longer compatible with EFI/VESA VGA. Keep setting orig_video_isVGA to EFI/VESA VGA flag will get wrong driver loaded and try to manipulate the framebuffer in a wrong way. We can't ensure this won't happen on other framebuffer drivers, But it's a helpful feature if the framebuffer drivers just work. So this patch introduce a --reuse-video-type options to let user decide if the old screen_info hould be used unconditional or not. Signed-off-by: Kairui Song <kasong@redhat.com> Reviewed-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-03-06kexec-tools 2.0.19.gitSimon Horman
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@verge.net.au>
2019-03-04kexec-tools 2.0.19Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-02-25kexec-tools 2.0.19-rc1Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-02-05arm64: wipe old initrd addresses when patching the DTBJean-Philippe Brucker
When copying the DTB from the current kernel, if the user didn't pass an initrd on the command-line, make sure that the new DTB doesn't contain initrd properties with stale addresses. Otherwise the next kernel will try to unpack the initramfs from a location that contains junk, since the initial initrd is long gone: [ 49.370026] Initramfs unpacking failed: junk in compressed archive This issue used to be hidden by a successful recovery, but since commit ff1522bb7d98 ("initramfs: cleanup incomplete rootfs") in Linux, the kernel removes the default /root mountpoint after failing to load an initramfs, and cannot mount the rootfs passed on the command-line anymore. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-02-05purgatory: Use standalond CFLAGSKairui Song
There has been a lot of workarounds for purgatory disabling many specified CFLAGS that will break purgatory. It will be better to not let the CFLAGS used to compile purgatory honor the CFLAGS from environment variables. So we will have stable CFLAGS for purgatory. If anyone still wants to change purgatory CFLAGS, PURGATORY_EXTRA_CFLAGS is still honored. Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-28x86: Handle 64bit framebuffer memory address properlyKairui Song
In a EFI system, the frame buffer address is 64bit, so currently if the address is beyound 4G, kexec will set wrong address due to truncate. Linux kernel commit ae2ee627dc87 ('efifb: Add support for 64-bit frame buffer addresses') added support for 64bit frame buffer address, an 'ext_lfb_base' field is added as the upper 32-bits of the frame buffer, and introduced a new capability flag 'VIDEO_TYPE_CAPABILITY_64BIT_BASE' to indicate if the extend field is used. This patch adopts this change, set proper extent address and capability flag when the address is beyound 4G. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-28multiboot-x86: pass framebuffer information when requestedFriedemann Gerold
When the kernel requests video information, pass it the framebuffer information in the multiboot header from the linux framebuffer ioctl's. With the arch specific --reset-vga or --consolve-vga options, purgatory will reset the framebuffer so pass information for standard ega text mode. Signed-off-by: Friedemann Gerold <cinap_lenrek@felloff.net> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-28multiboot-x86: pass ACPI reserved memory information in memory mapFriedemann Gerold
Use the appropriate types for ACPI reclaim and ACPI NVS ranges in the multiboot memory map. This allows the kernel to locate ACPI tables on UEFI systems without having a explicit pointer to the RSD. Signed-off-by: Friedemann Gerold <cinap_lenrek@felloff.net> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-28multiboot-x86: support for non-elf kernelsFriedemann Gerold
Add support for non-elf multiboot kernels (such as Plan 9) by handling the MULTIBOOT_AOUT_KLUDGE bit. When the bit is clear then we are dealing with an ELF file and probe for ELF as before with elf_x86_probe(). When the bit is set then load_addr, load_end_addr, header_addr and entry_addr from the multiboot header are used load the memory image. Signed-off-by: Friedemann Gerold <cinap_lenrek@felloff.net> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-15arm64: add kexec_file_load supportAKASHI Takahiro
With this patch, kexec_file_load() system call is supported. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com> Tested-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09arm64: Add support to read PHYS_OFFSET from 'kcore' - pt_note or pt_load (if ↵Bhupesh Sharma
available) On certain arm64 platforms, it has been noticed that due to a hole at the start of physical ram exposed to kernel (i.e. it doesn't start from address 0), the kernel still calculates the 'memstart_addr' kernel variable as 0. Whereas the SYSTEM_RAM or IOMEM_RESERVED range in '/proc/iomem' would carry a first entry whose start address is non-zero (as the physical ram exposed to the kernel starts from a non-zero address). In such cases, if we rely on '/proc/iomem' entries to calculate the phys_offset, then we will have mismatch between the user-space and kernel space 'PHYS_OFFSET' value. The present 'kexec-tools' code does the same in 'get_memory_ranges_iomem_cb()' function when it makes a call to 'set_phys_offset()'. This can cause the vmcore generated via 'kexec-tools' to miss the last few bytes as the first '/proc/iomem' starts from a non-zero address. Please see [0] for the original bug-report from Yanjiang Jin. The same can be fixed in the following manner: 1. For newer kernel (>= 4.19, with commit 23c85094fe1895caefdd ["proc/kcore: add vmcoreinfo note to /proc/kcore"] available), 'kcore' contains a new PT_NOTE which carries the VMCOREINFO information. If the same is available, one should prefer the same to retrieve 'PHYS_OFFSET' value exported by the kernel as this is now the standard interface exposed by kernel for sharing machine specific details with the user-land as per the arm64 kernel maintainers (see [1]) . 2. For older kernels, we can try and determine the PHYS_OFFSET value from PT_LOAD segments inside 'kcore' via some jugglery of the correct virtual and physical address combinations. As a fallback, we still support getting the PHYS_OFFSET values from '/proc/iomem', to maintain backward compatibility. Testing: ------- - Tested on my apm-mustang and qualcomm amberwing board with upstream kernel (4.20.0-rc7) for both KASLR and non-KASLR boot cases. References: ----------- [0] https://www.spinics.net/lists/kexec/msg20618.html [1] https://www.mail-archive.com/kexec@lists.infradead.org/msg20300.html Reported-by: Yanjiang Jin <yanjiang.jin@hxt-semitech.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09util_lib: Add functionality to read elf notesBhupesh Sharma
'vmcore-dmesg.c' already implements functionality to read 'vmcoreinfo' from vmcore file. The same can be used in other features as well (one of which is reading the elf notes from 'kcore' file), so there is merit in moving this to the utility libraries (util_lib). Newer kernel versions (>= 4.19, with commit 23c85094fe1895caefdd ["proc/kcore: add vmcoreinfo note to /proc/kcore"], available), have 'kcore' which now contains a new PT_NOTE which carries the VMCOREINFO information. If the same is available, we can benefit by using it in 'kexec-tools'. This is especially useful for architectures like arm64 as we can get kernel symbols like 'PHYS_OFFSET' from the '/proc/kcore' itself and use it to calculate 'phys_offset' before we make a call to 'set_phys_offset()'. For older kernels, we can try and determine the PHYS_OFFSET value from PT_LOAD segments inside 'kcore' via some jugglery of the correct virtual and physical address combinations. Subsequent patch(es) in this series will use the same feature to read the 'kcore' file. This patch also makes some of the functions which were earlier present in 'vmcore-dmesg.c' as non-static, so as to allow future patches to use them as library functions. Also we add the capability to read 'NUMBER(PHYS_OFFSET)' from vmcoreinfo to the already present 'scan_vmcoreinfo()' code. Future patches can look at reading more vmcoreinfo information (for e.g. 'kaslr_offset()' for x86_64 and arm64) by using the same framework. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09kexec/dt-ops.c: Fix '/chosen' v/s 'chosen' node being passed to fdt helper ↵Bhupesh Sharma
functions This patch fixes the incorrect 'chosen' node name being passed to various fdt helper functions inside 'kexec/dt-ops.c' As we can see from the Linux kernel usage inside 'drivers/firmware/efi/libstub/fdt.c', we pass '/chosen' node names to fdt helper function like 'fdt_path_offset()' whereas 'chosen' to the rest of the fdt helper functions like 'fdt_subnode_offset()'. We need to replicate the same in 'kexec-tools' to fix issues being reported when we use --dtb option while invoking 'kexec'. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09kexec/dt-ops.c: Fix adding '/chosen' node for cases where it is not ↵Bhupesh Sharma
available in dtb passed via --dtb option While calling 'kexec -l', in case we are passed a .dtb using --dtb option which doesn't contain a '/chosen' node, we try to create the '/chosen' node and add bootargs to this node. Currently the 'dt-ops.c' code is buggy as it passes '-FDT_ERR_NOTFOUND' to 'fdt_add_subnode()', which leads to the following error: # kexec -d --load Image --append 'debug' --dtb rk3399-sapphire.dtb <..snip..> dtb_set_property: fdt_add_subnode failed: FDT_ERR_NOTFOUND kexec: Set device tree bootargs failed. get_cells_size: #address-cells:2 #size-cells:2 cells_size_fitted: 0-0 cells_size_fitted: 0-0 setup_2nd_dtb: no kaslr-seed found This patch passes the correct nodeoffset value to 'fdt_add_subnode()', which fixes this issue: # kexec -d -l Image --append 'debug' --dtb rk3399-sapphire.dtb <..snip..> get_cells_size: #address-cells:2 #size-cells:2 cells_size_fitted: 0-0 cells_size_fitted: 0-0 setup_2nd_dtb: no kaslr-seed found Reported-by: Vicente Bergas <vicencb@gmail.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09kexec/kexec-arm64.c: Add error handling check against return value of ↵Bhupesh Sharma
'set_bootargs()' This patch adds missing error handling check against the return value of 'set_bootargs()' in 'kexec-arm64.c' Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-09kexec/dt-ops.c: Fix check against 'fdt_add_subnode' return valueBhupesh Sharma
Vicenç reported (via [1]) that currently executing kexec with '--dtb' option and passing a .dtb which doesn't have a '/chosen' node leads to the following error: # kexec -d --dtb dtb_without_chosen_node.dtb --append 'cmdline' --load Image dtb_set_property: fdt_add_subnode failed: <valid offset/length> kexec: Set device tree bootargs failed. This happens because currently we check the return value of 'fdt_add_subnode()' function call in 'dt-ops.c' incorrectly: result = fdt_add_subnode(new_dtb, nodeoffset, node); if (result) { dbgprintf("%s: fdt_add_subnode failed: %s\n", _func__, fdt_strerror(result)); goto on_error; } As we can see in 'fdt_rw.c', a positive return value from 'fdt_add_subnode()' function doesn't indicate an error. We can see that the Linux kernel (see 'drivers/firmware/efi/libstub/fdt.c' for example) also checks the 'fdt_add_subnode()' function against negative return values for errors. See an example below from 'update_fdt()' function in 'drivers/firmware/efi/libstub/fdt.c': node = fdt_add_subnode(fdt, 0, "chosen"); if (node < 0) { status = node; <..snip..> goto fdt_set_fail; } This patch fixes the same in 'kexec-tools'. [1]. http://lists.infradead.org/pipermail/kexec/2018-October/021746.html Cc: Simon Horman <horms@verge.net.au> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Reported-by: Vicente Bergas <vicencb@gmail.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
generated by cgit (git 2.34.1) at 2025-07-16 18:57:40 +0000