On Mon, Jun 03, 2024 at 08:06:56AM -0500, Kalra, Ashish wrote: > On 6/3/2024 3:56 AM, Borislav Petkov wrote > > > > EFI memory map and due to early allocation it uses memblock allocation. > > > > > > Later during boot, efi_enter_virtual_mode() calls kexec_enter_virtual_mode() > > > in case of a kexec-ed kernel boot. > > > > > > This function kexec_enter_virtual_mode() installs the new EFI memory map by > > > calling efi_memmap_init_late() which remaps the efi_memmap physically allocated > > > in efi_arch_mem_reserve(), but this remapping is still using memblock allocation. > > > > > > Subsequently, when memblock is freed later in boot flow, this remapped > > > efi_memmap will have random corruption (similar to a use-after-free scenario). > > > > > > The corrupted EFI memory map is then passed to the next kexec-ed kernel > > > which causes a panic when trying to use the corrupted EFI memory map. > > This sounds fishy: memblock allocated memory is not freed later in the > > boot - it remains reserved. Only free memory is freed from memblock to > > the buddy allocator. > > > > Or is the problem that memblock-allocated memory cannot be memremapped > > because *raisins*? > > This is what seems to be happening: > > efi_arch_mem_reserve() calls efi_memmap_alloc() to allocate memory for > EFI memory map and due to early allocation it uses memblock allocation. > > And later efi_enter_virtual_mode() calls kexec_enter_virtual_mode() > in case of a kexec-ed kernel boot. > > This function kexec_enter_virtual_mode() installs the new EFI memory map by > calling efi_memmap_init_late() which does memremap() on memblock-allocated memory. Does the issue happen only with SNP? I didn't really dig, but my theory would be that it has something to do with arch_memremap_can_ram_remap() in arch/x86/mm/ioremap.c > Thanks, Ashish -- Sincerely yours, Mike. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
