(cc Arvind)
On Tue, 5 Jan 2021 at 09:54, Lin Feng <linfen...@huawei.com> wrote: > > On efi64 x86_64 system, the EFI_CONVENTIONAL_MEMORY regions will not > be mapped when making EFI runtime calls. So kexec-tools can not get > these from /sys/firmware/efi/runtime-map. Then compressed boot os > can not get suitable regions in process_efi_entries and print debug > message as follow: > Physical KASLR disabled: no suitable memory region! > To enable physical kaslr with kexec, call process_e820_entries when > no suitable regions in efi memmaps. > > Signed-off-by: Lin Feng <linfen...@huawei.com> > > --- > > I find a regular of Kernel code and data placement with kexec. It > seems unsafe. The reason is showed above. > > I'm not familiar with efi firmware. I wonder if there are some risks > to get regions according to e820 when there is no suitable region > in efi memmaps. > --- > arch/x86/boot/compressed/kaslr.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/boot/compressed/kaslr.c > b/arch/x86/boot/compressed/kaslr.c > index b92fffbe761f..dbd7244b71aa 100644 > --- a/arch/x86/boot/compressed/kaslr.c > +++ b/arch/x86/boot/compressed/kaslr.c > @@ -685,6 +685,7 @@ process_efi_entries(unsigned long minimum, unsigned long > image_size) > { > struct efi_info *e = &boot_params->efi_info; > bool efi_mirror_found = false; > + bool efi_mem_region_found = false; > struct mem_vector region; > efi_memory_desc_t *md; > unsigned long pmap; > @@ -742,12 +743,13 @@ process_efi_entries(unsigned long minimum, unsigned > long image_size) > !(md->attribute & EFI_MEMORY_MORE_RELIABLE)) > continue; > > + efi_mem_region_found = false; > region.start = md->phys_addr; > region.size = md->num_pages << EFI_PAGE_SHIFT; > if (process_mem_region(®ion, minimum, image_size)) > break; > } > - return true; > + return efi_mem_region_found; > } > #else > static inline bool > -- > 2.23.0 >