mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-22 20:23:57 +08:00
afaef01c00
The STACKLEAK feature (initially developed by PaX Team) has the following benefits: 1. Reduces the information that can be revealed through kernel stack leak bugs. The idea of erasing the thread stack at the end of syscalls is similar to CONFIG_PAGE_POISONING and memzero_explicit() in kernel crypto, which all comply with FDP_RIP.2 (Full Residual Information Protection) of the Common Criteria standard. 2. Blocks some uninitialized stack variable attacks (e.g. CVE-2017-17712, CVE-2010-2963). That kind of bugs should be killed by improving C compilers in future, which might take a long time. This commit introduces the code filling the used part of the kernel stack with a poison value before returning to userspace. Full STACKLEAK feature also contains the gcc plugin which comes in a separate commit. The STACKLEAK feature is ported from grsecurity/PaX. More information at: https://grsecurity.net/ https://pax.grsecurity.net/ This code is modified from Brad Spengler/PaX Team's code in the last public patch of grsecurity/PaX based on our understanding of the code. Changes or omissions from the original code are ours and don't reflect the original grsecurity/PaX code. Performance impact: Hardware: Intel Core i7-4770, 16 GB RAM Test #1: building the Linux kernel on a single core 0.91% slowdown Test #2: hackbench -s 4096 -l 2000 -g 15 -f 25 -P 4.2% slowdown So the STACKLEAK description in Kconfig includes: "The tradeoff is the performance impact: on a single CPU system kernel compilation sees a 1% slowdown, other systems and workloads may vary and you are advised to test this feature on your expected workload before deploying it". Signed-off-by: Alexander Popov <alex.popov@linux.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org>
82 lines
4.0 KiB
Plaintext
82 lines
4.0 KiB
Plaintext
|
|
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 ...
|
|
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
|
|
[fixmap start] - ffffffffff5fffff kernel-internal fixmap range
|
|
ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
|
|
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
|
|
STACKLEAK_POISON value in this last hole: ffffffffffff4111
|
|
|
|
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 ...
|
|
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
|
|
[fixmap start] - ffffffffff5fffff kernel-internal fixmap range
|
|
ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
|
|
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
|
|
STACKLEAK_POISON value in this last hole: ffffffffffff4111
|
|
|
|
Architecture defines a 64-bit virtual address. Implementations can support
|
|
less. Currently supported are 48- and 57-bit virtual addresses. Bits 63
|
|
through to the most-significant implemented bit are sign extended.
|
|
This causes hole between user space and kernel addresses if you interpret them
|
|
as unsigned.
|
|
|
|
The direct mapping covers all memory in the system up to the highest
|
|
memory address (this means in some cases it can also include PCI memory
|
|
holes).
|
|
|
|
vmalloc space is lazily synchronized into the different PML4/PML5 pages of
|
|
the processes using the page fault handler, with init_top_pgt as
|
|
reference.
|
|
|
|
We map EFI runtime services in the 'efi_pgd' PGD in a 64Gb large virtual
|
|
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.
|
|
|
|
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.
|