Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

[Ingo Molnar]

* Baoquan He <bhe@xxxxxxxxxx> wrote:

> On 09/11/18 at 09:59am, Ingo Molnar wrote:
> > 
> > * Baoquan He <bhe@xxxxxxxxxx> wrote:
> > 
> > >  /*
> > > + * Memory regions randomized by KASLR (except modules that use a separate
> > > + * logic earlier during boot). Currently they are the physical memory
> > > + * mapping, vmalloc and vmemmap regions, are ordered based on virtual
> > > + * addresses. The order is kept after randomization.
> > > + *
> > > + * @base: points to various global variables used by the MM to get the
> > > + * virtual base address of the above regions, which base addresses can
> > > + * thus be modified by the very early KASLR code to dynamically shape
> > > + * the virtual memory layout of these kernel memory regions on a per
> > > + * bootup basis.
> > > + *
> > > + * @size_tb: size in TB of each memory region. Thereinto, the size of
> > > + * the physical memory mapping region is variable, calculated according
> > > + * to the actual size of system RAM in order to save more space for
> > > + * randomization. The rest are fixed values related to paging mode.
> > >   */
> > >  static __initdata struct kaslr_memory_region {
> > >  	unsigned long *base;
> > 
> > LGTM mostly, except the @size_tb field, see my comments further below.
> > 
> > Here's an edited version:
> > 
> > /*
> >  * 'struct kasl_memory_region' entries represent continuous chunks of
> >  * kernel virtual memory regions, to be randomized by KASLR.
> >  *
> >  * ( The exception is the module space virtual memory window which
> >  *   uses separate logic earlier during bootup. )
> >  *
> >  * Currently there are three such regions: the physical memory mapping,
> >  * vmalloc and vmemmap regions.
> >  *
> >  * The array below has the entries ordered based on virtual addresses.
> >  * The order is kept after randomization, i.e. the randomized
> >  * virtual addresses of these regions are still ascending.
> >  *
> >  * Here are the fields:
> >  *
> >  * @base: points to a global variable used by the MM to get the
> >  * virtual base address of any of the above regions. This allows the
> >  * early KASLR code to modify these base addresses early during bootup,
> >  * on a per bootup basis, without the MM code even being aware of whether
> >  * it got changed and to what value.
> >  *
> >  * When KASLR is active then the MM code makes sure that for each region
> >  * there's such a single, dynamic, global base address 'unsigned long'
> >  * variable available for the KASLR code to point to and modify directly:
> 
> >  *
> >  *       { &page_offset_base, 0 },
> >  *       { &vmalloc_base,     0 },
> >  *       { &vmemmap_base,     1 },
> >  *
> >  * @size_tb: size in TB of each memory region. Thereinto, the size of
> >  * the physical memory mapping region is variable, calculated according
> >  * to the actual size of system RAM in order to save more space for
> >  * randomization. The rest are fixed values related to paging mode.
> >  */
> > 
> > The role of @size_tb is still murky to me. What is it telling us?
> > Maximum virtual memory range to randomize into? Why does this depend
> > on system RAM at all - aren't these all virtual addresses in a 64-bit
> > (well, 48-bit or 56-bit) address ranges?
> 
> * @size_tb: size in TB of each memory region. Thereinto, the size of
> * the physical memory mapping region is variable, calculated according
> * to the actual size of system RAM. Since most of systems own RAM memory
> * which is much less than 64 TB which is reserved for mapping the maximum
> * physical memory in 4-level paging mode, not to mention 5-level. The
> * left space can be saved to enhance randomness.
> * 
> How about this?

Yeah, so proper context is still missing, this paragraph appears to assume from the reader a 
whole lot of prior knowledge, and this is one of the top comments in kaslr.c so there's nowhere 
else to go read about the background.

For example what is the range of randomization of each region? Assuming the static, 
non-randomized description in Documentation/x86/x86_64/mm.txt is correct, in what way does 
KASLR modify that layout?

All of this is very opaque and not explained very well anywhere that I could find. We need to 
generate a proper description ASAP.

> And please forgive my poor english.

No problem, I can prettify it afterwards, but the information is not there yet to prettify. :)

Thanks,

	Ingo