summaryrefslogtreecommitdiff
path: root/kexec/arch/arm64
AgeCommit message (Collapse)Author
2022-04-29arm64/crashdump-arm64: increase CRASH_MAX_MEMORY_RANGES to 32kabuehaze14
On ARM64 based VMs hotplugging more than 31GB of memory will cause kdump to fail loading as it's hitting the CRASH_MAX_MEMORY_RANGES limit which is currently 32 on ARM64 given that the memory block size is 1GB. This patch is raising CRASH_MAX_MEMORY_RANGES to 32K similar to what we have on x86, this should allow kdump to work until the VM has 32TB which should be enough for a long time. Signed-off-by: Hazem Mohamed Abuelfotoh <abuehaze@amazon.com> Acked-by: Baoquan He <bhe@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2022-04-01arm64: fix static data relocations in machine_apply_elf_rel()Pingfan Liu
As for 'static data relocations', instead of patching an instruction (OR ops), it should be assigned to value directly. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01arm64/crashdump-arm64: explicit type conversion to suppress compiler warningPingfan Liu
elf_info.page_offset is 'unsigned long long', while get_page_offset() has the input param as a type of 'unsigned long *'. It demands explicit type casting to mute the compiler warning. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01arm64/kexec-arm64: add support for R_AARCH64_MOVW_UABS_G* relaPingfan Liu
Build kexec-tools with clang(clang version 13.0.1 (Fedora 13.0.1-1.fc36)). Then when kexec loads kernel, it runs into the error message "machine_apply_elf_rel: ERROR Unknown type: 264". This is caused by the following reloc type in purgatory/purgatory.ro, which is not supported yet. R_AARCH64_MOVW_UABS_G0_NC R_AARCH64_MOVW_UABS_G1_NC R_AARCH64_MOVW_UABS_G2_NC R_AARCH64_MOVW_UABS_G3 Adding code to support these relocs, so kexec can work smoothly. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01arm64/kexec-arm64: use enum to organize the reloc typePingfan Liu
More and more reloc type need to be supported on aarch64. Using enum to organize them to shorten the #ifdef macro list. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01arm64/kexec-arm64: add support for R_AARCH64_LDST128_ABS_LO12_NC relaPingfan Liu
GCC 12 has some changes, which affects the generated AArch64 code of kexec-tools. Accordingly, a new rel type R_AARCH64_LDST128_ABS_LO12_NC is confronted by machine_apply_elf_rel() on AArch64. This fails the load of kernel with the message "machine_apply_elf_rel: ERROR Unknown type: 299" Citing from objdump -rDSl purgatory/purgatory.ro 0000000000000f80 <sha256_starts>: sha256_starts(): f80: 90000001 adrp x1, 0 <verify_sha256_digest> f80: R_AARCH64_ADR_PREL_PG_HI21 .text+0xfa0 f84: a9007c1f stp xzr, xzr, [x0] f88: 3dc00021 ldr q1, [x1] f88: R_AARCH64_LDST128_ABS_LO12_NC .text+0xfa0 f8c: 90000001 adrp x1, 0 <verify_sha256_digest> f8c: R_AARCH64_ADR_PREL_PG_HI21 .text+0xfb0 f90: 3dc00020 ldr q0, [x1] f90: R_AARCH64_LDST128_ABS_LO12_NC .text+0xfb0 f94: ad008001 stp q1, q0, [x0, #16] f98: d65f03c0 ret f9c: d503201f nop fa0: 6a09e667 .inst 0x6a09e667 ; undefined fa4: bb67ae85 .inst 0xbb67ae85 ; undefined fa8: 3c6ef372 .inst 0x3c6ef372 ; undefined fac: a54ff53a ld3w {z26.s-z28.s}, p5/z, [x9, #-3, mul vl] fb0: 510e527f sub wsp, w19, #0x394 fb4: 9b05688c madd x12, x4, x5, x26 fb8: 1f83d9ab .inst 0x1f83d9ab ; undefined fbc: 5be0cd19 .inst 0x5be0cd19 ; undefined Here, gcc generates codes, which make loads and stores carried out using the 128-bits floating-point registers. And a new rel type R_AARCH64_LDST128_ABS_LO12_NC should be handled. Make machine_apply_elf_rel() coped with this new reloc, so kexec-tools can work smoothly. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-24arm64: fix PAGE_OFFSET calc for flipped mmKairui Song
Since kernel commit 14c127c957c1 ('arm64: mm: Flip kernel VA space'), the memory layout on arm64 have changed, and kexec-tools can no longer get the the right PAGE_OFFSET based on _text symbol. Prior to that, the kimage (_text) lays above PAGE_END with this layout: 0 -> VA_START : Usespace VA_START -> VA_START + 256M : BPF JIT, Modules VA_START + 256M -> PAGE_OFFSET - (~GB misc) : Vmalloc (KERNEL _text HERE) PAGE_OFFSET -> ... : * Linear map * And here we have: VA_START = -1UL << VA_BITS PAGE_OFFSET = -1UL << (VA_BITS - 1) _text < -1UL << (VA_BITS - 1) Kernel image lays somewhere between VA_START and PAGE_OFFSET, so we just calc VA_BITS by getting the highest unset bit of _text symbol address, and shift one less bit of VA_BITS to get page offset. This works as long as KASLR don't put kernel in a too high location (which is commented inline). And after that commit, kernel layout have changed: 0 -> PAGE_OFFSET : Userspace PAGE_OFFSET -> PAGE_END : * Linear map * PAGE_END -> PAGE_END + 128M : bpf jit region PAGE_END + 128M -> PAGE_END + 256MB : modules PAGE_END + 256M -> ... : vmalloc (KERNEL _text HERE) Here we have: PAGE_OFFSET = -1UL << VA_BITS PAGE_END = -1UL << (VA_BITS - 1) _text > -1UL << (VA_BITS - 1) Kernel image now lays above PAGE_END, so we have to shift one more bit to get the VA_BITS, and shift the exact VA_BITS for PAGE_OFFSET. We can simply check if "_text > -1UL << (VA_BITS - 1)" is true to judge which layout is being used and shift the page offset occordingly. Signed-off-by: Kairui Song <kasong@tencent.com> (rebased and stripped by Pingfan ) Signed-off-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-24arm64: read VA_BITS from kcore for 52-bits VA kernelPingfan Liu
phys_to_virt() calculates virtual address. As a important factor, page_offset is excepted to be accurate. Since arm64 kernel exposes va_bits through vmcore, using it. Signed-off-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-24arm64/crashdump: unify routine to get page_offsetPingfan Liu
There are two funcs to get page_offset: get_kernel_page_offset() get_page_offset() Since get_kernel_page_offset() does not observe the kernel formula, and remove it. Unify them in order to introduce 52-bits VA kernel more easily in the coming patch. Signed-off-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-24arm64: make phys_offset signedPingfan Liu
After kernel commit 7bc1a0f9e176 ("arm64: mm: use single quantity to represent the PA to VA translation"), phys_offset can be negative if running 52-bits kernel on 48-bits hardware. So changing phys_offset from unsigned to signed. Signed-off-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-14arm64: support more than one crash kernel regionsChen Zhou
When crashkernel is reserved above 4G in memory, kernel should reserve some amount of low memory for swiotlb and some DMA buffers. So there may be two crash kernel regions, one is below 4G, the other is above 4G. Currently, there is only one crash kernel region on arm64, and pass "linux,usable-memory-range = <BASE SIZE>" property to crash dump kernel. Now, we pass "linux,usable-memory-range = <BASE1 SIZE1 BASE2 SIZE2>" to crash dump kernel to support two crash kernel regions and load crash kernel high. Make the low memory region as the second range "BASE2 SIZE2" to keep compatibility with existing user-space and older kdump kernels. Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Co-developed-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-12-15arm64/crashdump: deduce paddr of _text based on kernel code sizePingfan Liu
kexec-tools commit 61b8c79b0fb7 ("arm64/crashdump-arm64: deduce the paddr of _text") tries to deduce the paddr of _text, but turns out partially. That commit is based on "The Image must be placed text_offset bytes from a 2MB aligned base address anywhere in usable system RAM and called there" in linux/Documentation/arm64/booting.rst, plus text_offset field is zero. But in practice, some boot loaders does not obey the convention, and still boots up the kernel successfully. Revisiting kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from permanent kernel mapping"), the kernel code size changes from (unsigned long)__init_begin - (unsigned long)_text to (unsigned long)__init_begin - (unsigned long)_stext And it should be a better factor to decide which label starts the "Kernel code" in /proc/iomem. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-06-06arm64/crashdump-arm64: deduce the paddr of _textPingfan Liu
Since kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from permanent kernel mapping"), the physical address of 'Kernel code' in /proc/iomem is mapped from _text, instead, from _stext. Taking the compatibility into account, it had better deduce the paddr of _text despite of the unavailability through /proc/iomem. It can be achieved by utilizing the fact _text aligned on 2MB. Signed-off-by: Pingfan Liu <piliu@redhat.com> Cc: Simon Horman <horms@verge.net.au> To: kexec@lists.infradead.org Signed-off-by: Simon Horman <horms@verge.net.au>
2020-10-23arm64: Add purgatory printingMatthias Brugger
Add option to allow purgatory printing on arm64 hardware by passing the console name which should be used. Based on a patch by Geoff Levand. Signed-off-by: Matthias Brugger <mbrugger@suse.com> Acked-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-04-01kexec-tools: Remove duplicated variable declarationsKairui Song
When building kexec-tools for Fedora 32, following error is observed: /usr/bin/ld: kexec/arch/x86_64/kexec-bzImage64.o:(.bss+0x0): multiple definition of `bzImage_support_efi_boot'; kexec/arch/i386/kexec-bzImage.o:(.bss+0x0): first defined here /builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm/../../fs2dt.h:33: multiple definition of `my_debug'; kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/kexec/fs2dt.h:33: first defined here /builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:68: multiple definition of `arm64_mem'; kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:68: first defined here /builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:54: multiple definition of `initrd_size'; kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:54: first defined here /builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:53: multiple definition of `initrd_base'; kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:53: first defined here And apparently, these variables are wrongly declared multiple times. So remove duplicated declaration. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
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>
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-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-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-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-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-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>
2018-10-29arm64: If 'getrandom' syscall fails, don't error out - just warn and proceed.Bhupesh Sharma
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>
2018-06-29arm64: error out if kernel command line is too longMunehisa Kamata
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>
2018-06-29arm64: increase command line size to 2048Munehisa Kamata
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>
2018-06-19arm64: Add support to supply 'kaslr-seed' to secondary kernelBhupesh Sharma
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>
2017-05-22arm64: kdump: Add support for binary image filesPratyush Anand
This patch adds support to use binary image ie arch/arm64/boot/Image with kdump. Signed-off-by: Pratyush Anand <panand@redhat.com> [takahiro.akashi@linaro.org: a bit reworked] Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Pratyush Anand <panand@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2017-05-22arm64: kdump: add DT properties to crash dump kernel's dtbAKASHI Takahiro
We pass the following properties to crash dump kernel: linux,elfcorehdr: elf core header segment, same as "elfcorehdr=" kernel parameter on other archs linux,usable-memory-range: usable memory reserved for crash dump kernel Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Pratyush Anand <panand@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2017-05-22arm64: kdump: set up other segmentsAKASHI Takahiro
We make sure that all the other segments, initrd and device-tree blob, also be loaded into the reserved memory of crash dump kernel. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Pratyush Anand <panand@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2017-05-22arm64: kdump: set up kernel image segmentAKASHI Takahiro
On arm64, we can use the same kernel image as 1st kernel, but we have to modify the entry point as well as segments' addresses in the kernel's elf header in order to load them into correct places. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Pratyush Anand <panand@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2017-05-22arm64: kdump: add elf core header segmentAKASHI Takahiro
Elf core header contains the information necessary for the coredump of the 1st kernel, including its physcal memory layout as well as cpu register states at the panic. The segment is allocated inside the reserved memory of crash dump kernel. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Pratyush Anand <panand@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2017-05-22arm64: kdump: identify memory regionsAKASHI Takahiro
The following regions need to be identified for later use: a) memory regions which belong to the 1st kernel b) usable memory reserved for crash dump kernel We go through /proc/iomem to find out a) and b) which are marked as "System RAM" and "Crash kernel", respectively. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Pratyush Anand <panand@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2017-05-22arm64: change return values on error to negativeAKASHI Takahiro
EFAILED is defined "-1" and so we don't need to negate it as a return value. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Pratyush Anand <panand@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2017-05-22arm64: identify PHYS_OFFSET correctlyAKASHI Takahiro
Due to the kernel patch, commit e7cd190385d1 ("arm64: mark reserved memblock regions explicitly in iomem"), the current code will not be able to identify the correct value of PHYS_OFFSET if some "reserved" memory region, which is likely to be UEFI runtime services code/data, exists at an address below the first "System RAM" regions. This patch fixes this issue. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Pratyush Anand <panand@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2017-03-13arm64: add uImage supportDavid Woodhouse
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Simon Horman <horms@verge.net.au>
2017-03-02crashdump/arm64: Add get_crash_kernel_load_range() functionEric DeVolder
Provide stub get_crash_kernel_load_range() in support of print crash kernel region size option. Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2017-01-24kexec: Increase the upper limit for RAM segmentsSameer Goel
On a newer UEFI based Qualcomm target the number of system ram regions retrieved from /proc/iomem are ~40. So increasing the current hardcoded values to 64 from 16. Signed-off-by: Sameer Goel <sgoel@codeaurora.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2016-12-09arm64: Fix initrd requierementsMatthias Brugger
The initrd doesn't need to be aligend to 1 GB, which breaks kexec for system with RAM <= 1 GB. Instead the memory size between the kernel start rounded down to 1 GB and the end of the initrd rounded up to 1 GB can't be bigger then 32 GB. Signed-off-by: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2016-11-07arm64: Add support of R_AARCH64_PREL32 relocation in purgatoryPratyush Anand
gcc version in fedora koji is 6.2.1-2.fc25. kexec-tools compiled with this gcc produced another relocation error: machine_apply_elf_rel: ERROR Unknown type: 261 This patch fixes the above error. Signed-off-by: Pratyush Anand <panand@redhat.com> Reviewed-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2016-11-07arm64: Add support for additional relocations in the kexec purgatory codeCatalin Marinas
When compiling the kexec-tools with gcc6, the following additional reolcations are generated in the purgatory.ro file: R_AARCH64_ADR_PREL_PG_HI21 R_AARCH64_ADD_ABS_LO12_NC R_AARCH64_LDST64_ABS_LO12_NC This patch modifies the arm64 machine_apply_elf_rel() function to handle these relocations. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2016-10-13arm64: Add missing kexec dist filesGeoff Levand
Signed-off-by: Geoff Levand <geoff@infradead.org> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2016-10-13arm64: Cleanup kexec MakefileGeoff Levand
Put files in alphabetical order, reformat whitspace. Signed-off-by: Geoff Levand <geoff@infradead.org> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2016-09-29arm64: Add support for binary image filesPratyush Anand
Signed-off-by: Pratyush Anand <panand@redhat.com> [Reworked and cleaned up] Signed-off-by: Geoff Levand <geoff@infradead.org> Tested-By: Pratyush Anand <panand@redhat.com> Tested-By: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2016-09-29arm64: Add arm64 kexec supportGeoff Levand
Add kexec reboot support for ARM64 platforms. Signed-off-by: Geoff Levand <geoff@infradead.org> Tested-By: Pratyush Anand <panand@redhat.com> Tested-By: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Simon Horman <horms@verge.net.au>
generated by cgit (git 2.34.1) at 2025-07-30 16:08:03 +0000