[PATCH v2 0/3] x86/mm/doc: Clean up mm.txt

[PATCH v2 0/3] x86/mm/doc: Clean up mm.txt

[Baoquan He]

This clean up is suggested by Ingo.

It firstly fix the confusions in mm layout tables by unifying
each memory region description in the consistent style.

Secondly take the KASLR words out of the mm layout tables to make
it as a separate section to only list mm layout in non-KASLR case.
Then add KASLR document at the end of mm.txt.

Meanwhile update document about KERNEL_IMAGE_SIZE in
arch/x86/include/asm/page_64_types.h .

v1->v2:

Resend v2 since some typo and incorrect descriptions found in v1 post.

Baoquan He (3):
  x86/KASLR: Update document about KERNEL_IMAGE_SIZE
  x86/mm/doc: Clean up the memory region layout descriptions
  x86/doc/kaslr.txt: Create a separate part of document abourt KASLR at
    the end of file

 Documentation/x86/x86_64/mm.txt      | 140 +++++++++++++++++++++++------------
 arch/x86/include/asm/page_64_types.h |   7 +-
 2 files changed, 98 insertions(+), 49 deletions(-)

-- 
2.13.6

[PATCH v2 1/3] x86/KASLR: Update document about KERNEL_IMAGE_SIZE

[Baoquan He]

Currently CONFIG_RANDOMIZE_BASE=y is default set, update the relevant
document about KERNEL_IMAGE_SIZE.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 arch/x86/include/asm/page_64_types.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 6afac386a434..2288ceabdb9c 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -61,9 +61,10 @@
 /*
  * Kernel image size is limited to 1GiB due to the fixmap living in the
  * next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S). Use
- * 512MiB by default, leaving 1.5GiB for modules once the page tables
- * are fully set up. If kernel ASLR is configured, it can extend the
- * kernel page table mapping, reducing the size of the modules area.
+ * 1 GiB by default, leaving 1 GiB for modules once the page tables are
+ * fully set up. If kernel ASLR is not configured, it can shrink the
+ * kernel page table mapping to decrease the size of kernel area to 512
+ * MiB, increase the size of the modules area to 1.5 GiB.
  */
 #if defined(CONFIG_RANDOMIZE_BASE)
 #define KERNEL_IMAGE_SIZE	(1024 * 1024 * 1024)
-- 
2.13.6

[PATCH v2 2/3] x86/mm/doc: Clean up the memory region layout descriptions

[Baoquan He]

In Documentation/x86/x86_64/mm.txt, the style of descritions about
memory region layout is a little confusing:

 - mix size in TB with 'bits'
 - sometimes mention a size in the description and sometimes not
 - sometimes list holes by address, sometimes only as an 'unused hole' line

So fix them to make them in consistent style.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 Documentation/x86/x86_64/mm.txt | 76 ++++++++++++++++++++---------------------
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 5432a96d31ff..fc1da95e629d 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -1,52 +1,52 @@
 
 Virtual memory map with 4 level page tables:
 
-0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
-hole caused by [47:63] sign extension
-ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor
-ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory
-ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole
-ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space
-ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
-ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
-... unused hole ...
-ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB)
-... unused hole ...
+0000000000000000 - 00007fffffffffff (=47 bits, 128 TB) user space, different per mm
+				    hole caused by [47:63] sign extension
+ffff800000000000 - ffff87ffffffffff (=43 bits, 8 TB) guard hole, reserved for hypervisor
+ffff880000000000 - ffffc7ffffffffff (=46 bits, 64 TB) direct mapping of all phys. memory (page_offset_base)
+ffffc80000000000 - ffffc8ffffffffff (=40 bits, 1 TB) unused hole
+ffffc90000000000 - ffffe8ffffffffff (=45 bits, 32 TB) vmalloc/ioremap space (vmalloc_base)
+ffffe90000000000 - ffffe9ffffffffff (=40 bits, 1 TB) unused hole
+ffffea0000000000 - ffffeaffffffffff (=40 bits, 1 TB) virtual memory map (vmemmap_base)
+ffffeb0000000000 - ffffebffffffffff (=40 bits, 1 TB) unused hole
+ffffec0000000000 - fffffbffffffffff (=44 bits, 16 TB) kasan shadow memory
+fffffc0000000000 - fffffdffffffffff (=41 bits, 2 TB) unused hole
 				    vaddr_end for KASLR
-fffffe0000000000 - fffffe7fffffffff (=39 bits) cpu_entry_area mapping
-fffffe8000000000 - fffffeffffffffff (=39 bits) LDT remap for PTI
-ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
-... unused hole ...
-ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
-... unused hole ...
-ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
-ffffffffa0000000 - fffffffffeffffff (1520 MB) module mapping space
+fffffe0000000000 - fffffe7fffffffff (=39 bits, 512 GB) cpu_entry_area mapping
+fffffe8000000000 - fffffeffffffffff (=39 bits, 512 GB) LDT remap for PTI
+ffffff0000000000 - ffffff7fffffffff (=39 bits, 512 GB) %esp fixup stacks
+ffffff8000000000 - fffffffeefffffff (~39 bits, ~507 GB) unused hole
+ffffffef00000000 - fffffffeffffffff (=36 bits, 64 GB) EFI region mapping space
+ffffffff00000000 - ffffffff7fffffff (=31 bits, 2 GB) unused hole
+ffffffff80000000 - ffffffff9fffffff (=29 bits, 512 MB)  kernel text mapping, from phys 0
+ffffffffa0000000 - fffffffffeffffff (~31 bits, 1520 MB) module mapping space
 [fixmap start]   - ffffffffff5fffff kernel-internal fixmap range
 ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
 ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
 
 Virtual memory map with 5 level page tables:
 
-0000000000000000 - 00ffffffffffffff (=56 bits) user space, different per mm
-hole caused by [56:63] sign extension
-ff00000000000000 - ff0fffffffffffff (=52 bits) guard hole, reserved for hypervisor
-ff10000000000000 - ff8fffffffffffff (=55 bits) direct mapping of all phys. memory
-ff90000000000000 - ff9fffffffffffff (=52 bits) LDT remap for PTI
-ffa0000000000000 - ffd1ffffffffffff (=54 bits) vmalloc/ioremap space (12800 TB)
-ffd2000000000000 - ffd3ffffffffffff (=49 bits) hole
-ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB)
-... unused hole ...
-ffdf000000000000 - fffffc0000000000 (=53 bits) kasan shadow memory (8PB)
-... unused hole ...
+0000000000000000 - 00ffffffffffffff (=56 bits, 64 PB) user space, different per mm
+				    hole caused by [56:63] sign extension
+ff00000000000000 - ff0fffffffffffff (=52 bits, 4 PB) guard hole, reserved for hypervisor
+ff10000000000000 - ff8fffffffffffff (=55 bits, 32 PB) direct mapping of all phys. memory (page_offset_base)
+ff90000000000000 - ff9fffffffffffff (=52 bits, 4 PB) LDT remap for PTI
+ffa0000000000000 - ffd1ffffffffffff (=53 bits, 12800 TB) vmalloc/ioremap space (vmalloc_base)
+ffd2000000000000 - ffd3ffffffffffff (=49 bits, 512 TB) unused hole
+ffd4000000000000 - ffd5ffffffffffff (=49 bits, 512 TB) virtual memory map (vmemmap_base)
+ffd6000000000000 - ffdeffffffffffff (~51 bits, 2304 TB) unused hole
+ffdf000000000000 - fffffdffffffffff (~53 bits, ~8 PB) kasan shadow memory
+fffffc0000000000 - fffffdffffffffff (=41 bits, 2 TB) unused hole
 				    vaddr_end for KASLR
-fffffe0000000000 - fffffe7fffffffff (=39 bits) cpu_entry_area mapping
-... unused hole ...
-ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
-... unused hole ...
-ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
-... unused hole ...
-ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
-ffffffffa0000000 - fffffffffeffffff (1520 MB) module mapping space
+fffffe0000000000 - fffffe7fffffffff (=39 bits, 512 GB) cpu_entry_area mapping
+fffffe8000000000 - fffffeffffffffff (=39 bits, 512 GB) unused hole
+ffffff0000000000 - ffffff7fffffffff (=39 bits, 512 GB) %esp fixup stacks
+ffffff8000000000 - ffffffeeffffffff (~39 bits,  444 GB) unused hole
+ffffffef00000000 - fffffffeffffffff (=36 bits, 64 GB) EFI region mapping space
+ffffffff00000000 - ffffffff7fffffff (31 bits, 2 GB)  unused hole
+ffffffff80000000 - ffffffff9fffffff (=29 bits, 512 MB)  kernel text mapping, from phys 0
+ffffffffa0000000 - fffffffffeffffff (~31 bits, 1520 MB) module mapping space
 [fixmap start]   - ffffffffff5fffff kernel-internal fixmap range
 ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
 ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
-- 
2.13.6

[PATCH v2 3/3] x86/doc/kaslr.txt: Create a separate part of document abourt KASLR at the end of file

[Baoquan He]

Take the original content as the first part to only list static mm layout
tables in non-KASLR case. Then add KASLR document at the end.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 Documentation/x86/x86_64/mm.txt | 64 +++++++++++++++++++++++++++++++++++------
 1 file changed, 56 insertions(+), 8 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index fc1da95e629d..8147a137a99d 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -1,4 +1,7 @@
 
+MM layout in non-KASLR case:
+=================================
+
 Virtual memory map with 4 level page tables:
 
 0000000000000000 - 00007fffffffffff (=47 bits, 128 TB) user space, different per mm
@@ -12,7 +15,6 @@ ffffea0000000000 - ffffeaffffffffff (=40 bits, 1 TB) virtual memory map (vmemmap
 ffffeb0000000000 - ffffebffffffffff (=40 bits, 1 TB) unused hole
 ffffec0000000000 - fffffbffffffffff (=44 bits, 16 TB) kasan shadow memory
 fffffc0000000000 - fffffdffffffffff (=41 bits, 2 TB) unused hole
-				    vaddr_end for KASLR
 fffffe0000000000 - fffffe7fffffffff (=39 bits, 512 GB) cpu_entry_area mapping
 fffffe8000000000 - fffffeffffffffff (=39 bits, 512 GB) LDT remap for PTI
 ffffff0000000000 - ffffff7fffffffff (=39 bits, 512 GB) %esp fixup stacks
@@ -38,7 +40,6 @@ ffd4000000000000 - ffd5ffffffffffff (=49 bits, 512 TB) virtual memory map (vmemm
 ffd6000000000000 - ffdeffffffffffff (~51 bits, 2304 TB) unused hole
 ffdf000000000000 - fffffdffffffffff (~53 bits, ~8 PB) kasan shadow memory
 fffffc0000000000 - fffffdffffffffff (=41 bits, 2 TB) unused hole
-				    vaddr_end for KASLR
 fffffe0000000000 - fffffe7fffffffff (=39 bits, 512 GB) cpu_entry_area mapping
 fffffe8000000000 - fffffeffffffffff (=39 bits, 512 GB) unused hole
 ffffff0000000000 - ffffff7fffffffff (=39 bits, 512 GB) %esp fixup stacks
@@ -70,10 +71,57 @@ memory window (this size is arbitrary, it can be raised later if needed).
 The mappings are not part of any other kernel PGD and are only available
 during EFI runtime calls.
 
-Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
-physical memory, vmalloc/ioremap space and virtual memory map are randomized.
-Their order is preserved but their base will be offset early at boot time.
+Mm layout related to KASLR
+=========================================================================
+
+Kernel Adress Space Layout Randomization (KASLR) consists of two parts
+which work together to enhance the security of the Linux kernel:
+
+ - Kernel text KASLR
+ - Memory region KASLR
+
+Kernel text KASLR
+-----------------
+The physical address and virtual address of kernel text itself are
+randomized to a different position separately. The physical address of
+the kernel can be anywhere, under 64TB at most in 4-level paging mode,
+and under 4 PB in 5-level paging mode, while the virtual address of the
+kernel is restricted between [0xffffffff80000000, ffffffffbfffffff],
+the 1GB space.
+
+ffffffff80000000 - ffffffffbfffffff (1 GB)  kernel text mapping, from phys 0
+ffffffffc0000000 - fffffffffeffffff (1 GB) module mapping space
+
+Note: The kernel text KASLR uses 1 GB space to randomize the position of
+kernel image, and it's defalutly enabled. If KASLR config option
+CONFIG_RANDOMIZE_BASE is not enabled, the space for kernel image will be
+shrink to 512 MB, increase the size of modules area to 1.5 GB.
+
+Memory region KASLR
+-------------------
+If CONFIG_RANDOMIZE_MEMORY is enabled, the below three memory regions
+are randomized. Their order is preserved but their base will be offset
+early at boot time.
+
+   - direct mapping region
+   - vmalloc region
+   - vmemmap region
+
+The KASLR address range must not overlap with anything except the KASAN
+shadow area, which is correct as KASAN disables KASLR.
+
+So from the original starting address of the direct mapping region for physical
+RAM to the starting address of the cpu_entry_area mapping region, namely
+[0xffff880000000000 - 0xfffffdffffffffff], the scope of 118 TB in all is
+the virtual address space where memory region KASLR can be allowed to move
+those memory regions around. After KASLR manipulation is done, their layout
+looks like:
 
-Be very careful vs. KASLR when changing anything here. The KASLR address
-range must not overlap with anything except the KASAN shadow area, which is
-correct as KASAN disables KASLR.
+Name            Starting address        Size                                         Aligned
+-----------------------------------------------------------------------------------------------
+direct mapping  page_offset_base        [actual size of system RAM + 10 TB padding]  1 GB
+*guard hole     random                  random                                       1 GB
+vmalloc         vmalloc_base            32 TB                                        1 GB
+*guard hole     random                  random                                       1 GB
+vmemmap         vmemmap_base            1 TB                                         1 GB
+*guard hole     random                  random                                       1 GB
-- 
2.13.6

Re: [PATCH v2 2/3] x86/mm/doc: Clean up the memory region layout descriptions

[Ingo Molnar]

* Baoquan He <bhe@redhat.com> wrote:

> In Documentation/x86/x86_64/mm.txt, the style of descritions about
> memory region layout is a little confusing:
> 
>  - mix size in TB with 'bits'
>  - sometimes mention a size in the description and sometimes not
>  - sometimes list holes by address, sometimes only as an 'unused hole' line
> 
> So fix them to make them in consistent style.
> 
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
>  Documentation/x86/x86_64/mm.txt | 76 ++++++++++++++++++++---------------------
>  1 file changed, 38 insertions(+), 38 deletions(-)
> 
> diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
> index 5432a96d31ff..fc1da95e629d 100644
> --- a/Documentation/x86/x86_64/mm.txt
> +++ b/Documentation/x86/x86_64/mm.txt
> @@ -1,52 +1,52 @@
>  
>  Virtual memory map with 4 level page tables:
>  
> -0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
> -hole caused by [47:63] sign extension
> -ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor
> -ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory
> -ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole
> -ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space
> -ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
> -ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
> -... unused hole ...
> -ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB)
> -... unused hole ...
> +0000000000000000 - 00007fffffffffff (=47 bits, 128 TB) user space, different per mm
> +				    hole caused by [47:63] sign extension
> +ffff800000000000 - ffff87ffffffffff (=43 bits, 8 TB) guard hole, reserved for hypervisor
> +ffff880000000000 - ffffc7ffffffffff (=46 bits, 64 TB) direct mapping of all phys. memory (page_offset_base)
> +ffffc80000000000 - ffffc8ffffffffff (=40 bits, 1 TB) unused hole
> +ffffc90000000000 - ffffe8ffffffffff (=45 bits, 32 TB) vmalloc/ioremap space (vmalloc_base)
> +ffffe90000000000 - ffffe9ffffffffff (=40 bits, 1 TB) unused hole
> +ffffea0000000000 - ffffeaffffffffff (=40 bits, 1 TB) virtual memory map (vmemmap_base)
> +ffffeb0000000000 - ffffebffffffffff (=40 bits, 1 TB) unused hole
> +ffffec0000000000 - fffffbffffffffff (=44 bits, 16 TB) kasan shadow memory
> +fffffc0000000000 - fffffdffffffffff (=41 bits, 2 TB) unused hole
>  				    vaddr_end for KASLR
> -fffffe0000000000 - fffffe7fffffffff (=39 bits) cpu_entry_area mapping
> -fffffe8000000000 - fffffeffffffffff (=39 bits) LDT remap for PTI
> -ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
> -... unused hole ...
> -ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
> -... unused hole ...
> -ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
> -ffffffffa0000000 - fffffffffeffffff (1520 MB) module mapping space
> +fffffe0000000000 - fffffe7fffffffff (=39 bits, 512 GB) cpu_entry_area mapping
> +fffffe8000000000 - fffffeffffffffff (=39 bits, 512 GB) LDT remap for PTI
> +ffffff0000000000 - ffffff7fffffffff (=39 bits, 512 GB) %esp fixup stacks
> +ffffff8000000000 - fffffffeefffffff (~39 bits, ~507 GB) unused hole
> +ffffffef00000000 - fffffffeffffffff (=36 bits, 64 GB) EFI region mapping space
> +ffffffff00000000 - ffffffff7fffffff (=31 bits, 2 GB) unused hole
> +ffffffff80000000 - ffffffff9fffffff (=29 bits, 512 MB)  kernel text mapping, from phys 0
> +ffffffffa0000000 - fffffffffeffffff (~31 bits, 1520 MB) module mapping space
>  [fixmap start]   - ffffffffff5fffff kernel-internal fixmap range
>  ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
>  ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole

Looks mostly good now, but could you please make the right side align vertically as well, like 
I did in the examples I provided previously?

There's zero reason for it to look this disorganized:

> +ffffff8000000000 - fffffffeefffffff (~39 bits, ~507 GB) unused hole
> +ffffffef00000000 - fffffffeffffffff (=36 bits, 64 GB) EFI region mapping space
> +ffffffff00000000 - ffffffff7fffffff (=31 bits, 2 GB) unused hole
> +ffffffff80000000 - ffffffff9fffffff (=29 bits, 512 MB)  kernel text mapping, from phys 0

I.e. can we do something like:

> +ffffff8000000000 - fffffffeefffffff (~39 bits, ~507 GB) unused hole
> +ffffffef00000000 - fffffffeffffffff (=36 bits,   64 GB) EFI region mapping space
> +ffffffff00000000 - ffffffff7fffffff (=31 bits,    2 GB) unused hole
> +ffffffff80000000 - ffffffff9fffffff (=29 bits,  512 MB) kernel text mapping, from phys 0

?

That not only makes it more readable, but makes typos like the whitespace noise double space in 
the last line more obvious.

Thanks,

	Ingo

Re: [PATCH v2 1/3] x86/KASLR: Update document about KERNEL_IMAGE_SIZE

[Ingo Molnar]

* Baoquan He <bhe@redhat.com> wrote:

> Currently CONFIG_RANDOMIZE_BASE=y is default set, update the relevant
> document about KERNEL_IMAGE_SIZE.

Suggested wording:

  x86/KASLR: Update KERNEL_IMAGE_SIZE description
  
  Currently CONFIG_RANDOMIZE_BASE=y is set by default, which makes some of the
  old comments above the KERNEL_IMAGE_SIZE definition out of date. Update them
  to the current state of affairs.

> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
>  arch/x86/include/asm/page_64_types.h | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
> index 6afac386a434..2288ceabdb9c 100644
> --- a/arch/x86/include/asm/page_64_types.h
> +++ b/arch/x86/include/asm/page_64_types.h
> @@ -61,9 +61,10 @@
>  /*
>   * Kernel image size is limited to 1GiB due to the fixmap living in the
>   * next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S). Use
> - * 512MiB by default, leaving 1.5GiB for modules once the page tables
> - * are fully set up. If kernel ASLR is configured, it can extend the
> - * kernel page table mapping, reducing the size of the modules area.
> + * 1 GiB by default, leaving 1 GiB for modules once the page tables are
> + * fully set up. If kernel ASLR is not configured, it can shrink the
> + * kernel page table mapping to decrease the size of kernel area to 512
> + * MiB, increase the size of the modules area to 1.5 GiB.
>   */

I've prettified that comment some more:

 /*
  * Maximum kernel image size is limited to 1 GiB, due to the fixmap living
  * in the next 1 GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S).
  *
  * On KASLR use 1 GiB by default, leaving 1 GiB for modules once the
  * page tables are fully set up.
  *
  * If KASLR is disabled we can shrink it to 0.5 GiB and increase the size
  * of the modules area to 1.5 GiB.
  */

>  #if defined(CONFIG_RANDOMIZE_BASE)
>  #define KERNEL_IMAGE_SIZE	(1024 * 1024 * 1024)

BTW., while at it, shouldn't we make that:

   #ifdef CONFIG_RANDOMIZE_BASE

?

Thanks,

	Ingo

Re: [PATCH v2 1/3] x86/KASLR: Update document about KERNEL_IMAGE_SIZE

[Baoquan He]

On 10/03/18 at 09:52am, Ingo Molnar wrote:
> 
> * Baoquan He <bhe@redhat.com> wrote:
> 
> > Currently CONFIG_RANDOMIZE_BASE=y is default set, update the relevant
> > document about KERNEL_IMAGE_SIZE.
> 
> Suggested wording:
> 
>   x86/KASLR: Update KERNEL_IMAGE_SIZE description
>   
>   Currently CONFIG_RANDOMIZE_BASE=y is set by default, which makes some of the
>   old comments above the KERNEL_IMAGE_SIZE definition out of date. Update them
>   to the current state of affairs.

Thanks, will update with this.

> 
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > ---
> >  arch/x86/include/asm/page_64_types.h | 7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
> > index 6afac386a434..2288ceabdb9c 100644
> > --- a/arch/x86/include/asm/page_64_types.h
> > +++ b/arch/x86/include/asm/page_64_types.h
> > @@ -61,9 +61,10 @@
> >  /*
> >   * Kernel image size is limited to 1GiB due to the fixmap living in the
> >   * next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S). Use
> > - * 512MiB by default, leaving 1.5GiB for modules once the page tables
> > - * are fully set up. If kernel ASLR is configured, it can extend the
> > - * kernel page table mapping, reducing the size of the modules area.
> > + * 1 GiB by default, leaving 1 GiB for modules once the page tables are
> > + * fully set up. If kernel ASLR is not configured, it can shrink the
> > + * kernel page table mapping to decrease the size of kernel area to 512
> > + * MiB, increase the size of the modules area to 1.5 GiB.
> >   */
> 
> I've prettified that comment some more:

Thanks, will use them.

> 
>  /*
>   * Maximum kernel image size is limited to 1 GiB, due to the fixmap living
>   * in the next 1 GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S).
>   *
>   * On KASLR use 1 GiB by default, leaving 1 GiB for modules once the
>   * page tables are fully set up.
>   *
>   * If KASLR is disabled we can shrink it to 0.5 GiB and increase the size
>   * of the modules area to 1.5 GiB.
>   */
> 
> >  #if defined(CONFIG_RANDOMIZE_BASE)
> >  #define KERNEL_IMAGE_SIZE	(1024 * 1024 * 1024)
> 
> BTW., while at it, shouldn't we make that:
> 
>    #ifdef CONFIG_RANDOMIZE_BASE

Yes, makes sense, will change.

> 
> ?
> 
> Thanks,
> 
> 	Ingo

Re: [PATCH v2 2/3] x86/mm/doc: Clean up the memory region layout descriptions

[Baoquan He]

On 10/02/18 at 11:14am, Ingo Molnar wrote:
> 
> * Baoquan He <bhe@redhat.com> wrote:
> > -ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
> > -ffffffffa0000000 - fffffffffeffffff (1520 MB) module mapping space
> > +fffffe0000000000 - fffffe7fffffffff (=39 bits, 512 GB) cpu_entry_area mapping
> > +fffffe8000000000 - fffffeffffffffff (=39 bits, 512 GB) LDT remap for PTI
> > +ffffff0000000000 - ffffff7fffffffff (=39 bits, 512 GB) %esp fixup stacks
> > +ffffff8000000000 - fffffffeefffffff (~39 bits, ~507 GB) unused hole
> > +ffffffef00000000 - fffffffeffffffff (=36 bits, 64 GB) EFI region mapping space
> > +ffffffff00000000 - ffffffff7fffffff (=31 bits, 2 GB) unused hole
> > +ffffffff80000000 - ffffffff9fffffff (=29 bits, 512 MB)  kernel text mapping, from phys 0
> > +ffffffffa0000000 - fffffffffeffffff (~31 bits, 1520 MB) module mapping space
> >  [fixmap start]   - ffffffffff5fffff kernel-internal fixmap range
> >  ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
> >  ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
> 
> Looks mostly good now, but could you please make the right side align vertically as well, like 
> I did in the examples I provided previously?
> 
> There's zero reason for it to look this disorganized:
> 
> > +ffffff8000000000 - fffffffeefffffff (~39 bits, ~507 GB) unused hole
> > +ffffffef00000000 - fffffffeffffffff (=36 bits, 64 GB) EFI region mapping space
> > +ffffffff00000000 - ffffffff7fffffff (=31 bits, 2 GB) unused hole
> > +ffffffff80000000 - ffffffff9fffffff (=29 bits, 512 MB)  kernel text mapping, from phys 0
> 
> I.e. can we do something like:
> 
> > +ffffff8000000000 - fffffffeefffffff (~39 bits, ~507 GB) unused hole
> > +ffffffef00000000 - fffffffeffffffff (=36 bits,   64 GB) EFI region mapping space
> > +ffffffff00000000 - ffffffff7fffffff (=31 bits,    2 GB) unused hole
> > +ffffffff80000000 - ffffffff9fffffff (=29 bits,  512 MB) kernel text mapping, from phys 0

Sure, will change according to your suggestion. Thanks a lot!

> 
> ?
> 
> That not only makes it more readable, but makes typos like the whitespace noise double space in 
> the last line more obvious.
> 
> Thanks,
> 
> 	Ingo