Re: [PATCH v5 4/4] x86/mm/KASLR: Adjust the padding size for the direct mapping.

[Baoquan He <bhe@redhat.com>]

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