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

[Baoquan He <bhe@redhat.com>]

On 09/21/18 at 11:21am, Baoquan He wrote:
> 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 | 62 +++++++++++++++++++++++++++++++++++------
>  1 file changed, 54 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
> index fc1da95e629d..58187614c7ca 100644
> --- a/Documentation/x86/x86_64/mm.txt
> +++ b/Documentation/x86/x86_64/mm.txt
> @@ -1,4 +1,6 @@
>  
> +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 +14,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 +39,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 +70,56 @@ 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.
> +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, while the virtual address of the
				    ~~~ in 4-level paging mode
> +kernel is restricted between [0xffffffff80000000, ffffffffbfffffff],
> +the 1GB space.
> +
> +ffffffff80000000 - ffffffffbfffffff (1 GB)  kernel text mapping, from phys 0
> +ffffffffc0000000 - fffffffffeffffff (1520 MB) module mapping space
					1 GB too, will repost.
> +
> +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
>