On Mon, 31 May 2021 at 11:57, Marc Zyngier maz@kernel.org wrote:
It has been reported that kexec_file doesn't really work on arm64. It completely ignores any of the existing reservations, which results in the secondary kernel being loaded where the GICv3 LPI tables live, or even corrupting the ACPI tables.
Since only crash kernels are imune to this as they use a reserved memory region, disable the non-crash kernel use case. Further patches will try and restore the functionality.
Reported-by: Moritz Fischer mdf@kernel.org Signed-off-by: Marc Zyngier maz@kernel.org Cc: stable@vger.kernel.org # 5.10
Acked-by: Ard Biesheuvel ardb@kernel.org
... but do we really only need this in 5.10 and not earlier?
arch/arm64/kernel/kexec_image.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c index 9ec34690e255..acf9cd251307 100644 --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -145,3 +145,23 @@ const struct kexec_file_ops kexec_image_ops = { .verify_sig = image_verify_sig, #endif };
+/**
- arch_kexec_locate_mem_hole - Find free memory to place the segments.
- @kbuf: Parameters for the memory search.
- On success, kbuf->mem will have the start address of the memory region found.
- Return: 0 on success, negative errno on error.
- */
+int arch_kexec_locate_mem_hole(struct kexec_buf *kbuf) +{
/** For the time being, kexec_file_load isn't reliable except* for crash kernel. Say sorry to the user.*/if (kbuf->image->type != KEXEC_TYPE_CRASH)return -EADDRNOTAVAIL;return kexec_locate_mem_hole(kbuf);+}
2.30.2