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@xxxxxxxxxx> > --- > 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 >
