Messages in this thread | | | Date | Thu, 12 Dec 2019 21:19:16 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH v5 4/4] x86/mm/KASLR: Adjust the padding size for the direct mapping. |
| |
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
| |