| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes: 22a2ed55132e ("x86: Support multiboot2 images")
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
'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>
|
|
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>
|
|
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>
|
|
'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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For calculating the random 'kaslr-seed' value to be passed to the
secondary kernel (kexec or kdump), we invoke the 'getrandom' syscall
inside 'setup_2nd_dtb()' function.
Normally on most arm64 systems this syscall doesn't fail when the
initrd scriptware (which arms kdump service) invokes the same.
However, recently I noticed that on the 'hp-moonshot' arm64 boards,
we have an issue with the newer kernels which causes the same
to fail. As a result, the kdump service fails and we are not able
to use the kdump infrastructure just after boot. As expected, once the
random pool is sufficiently populated and we launch the kdump service
arming scripts again (manually), then the kdump service is properly
enabled.
Lets handle the same, by not error'ing out if 'getrandom' syscall fails.
Rather lets warn the user and proceed further by setting the
'kaslr-seed' value as 0 for the secondary kernel - which implies that it
boots in a 'nokaslr' mode.
Tested on my 'hp-moonshot' and 'qualcomm-amberwing' arm64 boards.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If the err_out label is reached, address of a stack variable is passed to
free(). Fix it.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When kexec-tools load the kernel and initramfs for kdump, kexec-tools will
read /proc/iomem and recreate the e820 ranges for kdump kernel. But it fails
to parse the e820 reserved region, because the memcmp() is case sensitive
when comparing the string. In fact, it may be "Reserved" or "reserved" in
the /proc/iomem, so we have to fix these cases.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In response to a change in binutils, commit b21ebf2fb4c
(x86: Treat R_X86_64_PLT32 as R_X86_64_PC32) was applied to
the linux kernel during the 4.16 development cycle and has
since been backported to earlier stable kernel series. The
change results in the failure message in $SUBJECT when
rebooting via kexec.
Fix this by replicating the change in kexec.
Signed-off-by: Chris Clayton <chris2553@googlemail.com>
Acked-by: Baoquan He <bhe@redhat.com>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently, in arm64, kexec silently truncates kernel command line longer
than COMMAND_LINE_SIZE - 1. Error out in that case as some other
architectures already do that. The error message is copied from x86_64.
Suggested-by: Tom Kirchner <tjk@amazon.com>
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Otherwise, we can hit the current 512 chars limit before hitting the
Linux kernel's one, where allows 2048 chars in arm64.
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch adds the support to supply 'kaslr-seed' to secondary kernel,
when we do a 'kexec warm reboot to another kernel' (although the
behaviour remains the same for the 'kdump' case as well) on arm64
platforms using the 'kexec_load' invocation method.
Lets consider the case where the primary kernel working on the arm64
platform supports kaslr (i.e 'CONFIG_RANDOMIZE_BASE' was set to y and
we have a compliant EFI firmware which supports EFI_RNG_PROTOCOL and
hence can pass a non-zero (valid) seed to the primary kernel).
Now the primary kernel reads the 'kaslr-seed' and wipes it to 0 and
uses the seed value to randomize for e.g. the module base address
offset.
In the case of 'kexec_load' (or even kdump for brevity),
we rely on the user-space kexec-tools to pass an appropriate dtb to the
secondary kernel and since 'kaslr-seed' is wiped to 0 by the primary
kernel, the secondary will essentially work with *nokaslr* as
'kaslr-seed' is set to 0 when it is passed to the secondary kernel.
This can be true even in case the secondary kernel had
'CONFIG_RANDOMIZE_BASE' and 'CONFIG_RANDOMIZE_MODULE_REGION_FULL' set to
y.
This patch addresses this issue by first checking if the device tree
provided by the firmware to the kernel supports the 'kaslr-seed'
property and verifies that it is really wiped to 0. If this condition is
met, it fixes up the 'kaslr-seed' property by using the getrandom()
syscall to get a suitable random number.
I verified this patch on my Qualcomm arm64 board and here are some test
results:
1. Ensure that the primary kernel is boot'ed with 'kaslr-seed'
dts property and it is really wiped to 0:
[root@qualcomm-amberwing]# dtc -I dtb -O dts /sys/firmware/fdt | grep -A 10 -i chosen
chosen {
kaslr-seed = <0x0 0x0>;
...
}
2. Now issue 'kexec_load' to load the secondary kernel (let's assume
that we are using the same kernel as the secondary kernel):
# kexec -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
-r`.img --reuse-cmdline -d
3. Issue 'kexec -e' to warm boot to the secondary:
# kexec -e
4. Now after the secondary boots, confirm that the load address of the
modules is randomized in every successive boot:
[root@qualcomm-amberwing]# cat /proc/modules
sunrpc 524288 1 - Live 0xffff0307db190000
vfat 262144 1 - Live 0xffff0307db110000
fat 262144 1 vfat, Live 0xffff0307db090000
crc32_ce 262144 0 - Live 0xffff0307d8c70000
...
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The kdump tool presently allows one to generate an ELF file containing
the ELF header, PT_NOTE and PT_LOAD segments (which can be analyzed
later by tools like 'readelf') of the crashdump read from memory, when
passed with an appropriate 'elfcorehdr' value(which represents the
physical address of the start of the ELF header).
With the availability of tools like crash/gdb the analysis of the
crashdump core has become rather easy, and it makes the kdump tool
obsolete. Also the same naming convention (man page) causes confusion
when compared to similarly named distribution specific kdump
service/utilities.
Also most distributions (like Fedora for e.g.) now support more
enhanced kdump service and utilities which can be used to analyze the
crashdump core contents better. Taking an example of the Fedora
specific kdump service and utilities, the following sequence of steps
happen when the primary kernel crashes:
1. If the crashkernel is loaded, then the system starts executing the
same.
2. When the boot process gets to the point when kdump service is
started, the crashdump core is usually copied out to disk (for e.g.
inside '/var/crash') using 'cp' command from '/proc/vmcore':
# cp /proc/vmcore <dump-file>
3. Thereafter the system is rebooted back into the normal kernel.
4. Once back to your normal kernel, one can use the crashdump core
available on hard disk in conjunction with the previously installed
kernel (with debuginfo) to perform postmortem analysis with tools like
gdb/crash:
# gdb vmlinux <dump-file>
Accordingly, this patch removes the obsolete kdump tool from
'kexec-tools'.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Presently the Makedumpfile.in doesn't include a uninstall rule, which is
useful in case we want to preform a reverse of the install process
done by Makefile.in
This patch adds this rule, thus making it easier to remove installed
executables and man pages in case one needs to uninstall the same.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We hit a bug where vmcore-dmesg would get stuck in a loop, and since we
were redirecting the output to a file, it wouldn't stop until it filled
up the disk. This only happened when the dmesg buffer had filled up and
wrapped around. It turns out that when we hit the end of the buffer, we
are looping back to the first record instead of the beginning of the
buffer, which will always loop forever.
Fixes: e08d26b3b7f1 ("vmcore-dmesg: avoid allocating large memory chunk for log buf")
Signed-off-by: Omar Sandoval <osandov@fb.com>
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
