| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20180921052327.GA32486@MiWiFi-R3L-srv>
Date: Fri, 21 Sep 2018 13:23:27 +0800
From: Baoquan He <bhe@...hat.com>
To: mingo@...nel.org, tglx@...utronix.de, hpa@...or.com
Cc: linux-kernel@...r.kernel.org, kirill.shutemov@...ux.intel.com,
x86@...nel.org, thgarnie@...gle.com, corbet@....net,
linux-doc@...r.kernel.org, peterz@...radead.org
Subject: Re: [PATCH v2 3/3] x86/doc/kaslr.txt: Create a separate part of
document abourt KASLR at the end of file
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@...hat.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
>
Powered by blists - more mailing lists