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

[Borislav Petkov]

On Fri, Nov 15, 2019 at 09:49:17AM -0500, Masayoshi Mizuma wrote:
> +/*
> + * Even though a huge virtual address space is reserved for the direct
> + * mapping of physical memory, e.g in 4-level paging mode, it's 64TB,
> + * rare system can own enough physical memory to use it up, most are
> + * even less than 1TB.

This sentence is unparseable.

> So with KASLR enabled, we adapt the size of

Who's "we"?

> + * 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.

> +{
> +	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()?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette