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 --- 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); +}
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
On Mon, 31 May 2021 20:37:49 +0100, Ard Biesheuvel ardb@kernel.org wrote:
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?
We *do* need something in earlier kernel (as mentioned in the cover letter), but not this patch (arch_kexec_locate_mem_hole doesn't exist there, so there is nothing to override).
I guess that completely disabling CONFIG_KEXEC_FILE on arm64 is the way to go for 5.4 and earlier, as I don't think there is any crash kernel support there.
Thanks,
M.
On 31/05/2021 10:57, Marc Zyngier 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.
I'd like to know how the ACPI tables bit happens.
ACPI tables should be in EFI_ACPI_RECLAIM_MEMORY or EFI_ACPI_MEMORY_NVS (which isn't treated as usable).
EFI's reserve_regions() does this: | if (!is_usable_memory(md)) | memblock_mark_nomap(paddr, size); | | /* keep ACPI reclaim memory intact for kexec etc. */ | if (md->type == EFI_ACPI_RECLAIM_MEMORY) | memblock_reserve(paddr, size);
which is called via efi_init(), and all those regions end up listed as reserved in /proc/iomem. (this is why arm64 doesn't call acpi_reserve_initial_tables())
If your firmware puts ACPI tables are in EFI_CONVENTIONAL_MEMORY, you have bigger problems as the kernel could get relocated over the top of them during boot, and even if it doesn't, nothing stops that memory being allocated for user-space.
Even acpi_table_upgrade() calls memblock_reserve() and happens early enough not to be a problem.
Please share ... enjoyment, optional.
(boot with efi=debug and post the EFI memory map and the 'ACPI: FOO 0xphysicaladdress' stuff at the top of the boot log)
Thanks,
James
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.
linux-stable-mirror@lists.linaro.org
-
Ard Biesheuvel -
James Morse -
Marc Zyngier