Messages in this thread | | | Date | Fri, 13 Dec 2019 21:28:50 +0800 | From | Baoquan He <> | Subject | Re: [PATCH v5 4/4] x86/mm/KASLR: Adjust the padding size for the direct mapping. |
| |
On 12/12/19 at 09:19pm, Borislav Petkov wrote: > > + * direct mapping area to the size of actual physical memory plus the > > + * configured padding CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING. > > + * The left part will be taken out to join memory randomization. > > + */ > > +static inline unsigned long calc_direct_mapping_size(void) > > What direct mapping?! > > The code is computing the physical memory regions base address and > sizes.
In Documentation/x86/x86_64/mm.rst, the physical memory regions mapping with page_offset is called as the direct mapping of physical memory. Seems both is used in kernel and document.
> > > +{ > > + unsigned long size_tb, memory_tb; > > + > > + memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) + > > + CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING; > > + > > +#ifdef CONFIG_MEMORY_HOTPLUG > > + if (boot_params.max_addr) { > > + unsigned long maximum_tb; > > + > > + maximum_tb = DIV_ROUND_UP(boot_params.max_addr, > > + 1UL << TB_SHIFT); > > All that jumping through hoops and adding a member to boot_params which > is useless on !hot-add systems - basically the majority out there - just > so that you can use that max address here?! > > Did you not find acpi_table_parse_srat()?
kernel_randomize_memory() is invoked much earlier than acpi_table_parse_srat(). KASLR need know the max address to reserve space for the direct mapping region (or the physical memory region) so that it can cover later possible hotplugged memory.
Thanks Baoquan
| |