]> git.proxmox.com Git - pve-kernel.git/blobdiff - patches/kernel/0236-x86-mm-Set-MODULES_END-to-0xffffffffff000000.patch
KPTI: add follow-up fixes
[pve-kernel.git] / patches / kernel / 0236-x86-mm-Set-MODULES_END-to-0xffffffffff000000.patch
diff --git a/patches/kernel/0236-x86-mm-Set-MODULES_END-to-0xffffffffff000000.patch b/patches/kernel/0236-x86-mm-Set-MODULES_END-to-0xffffffffff000000.patch
new file mode 100644 (file)
index 0000000..73f852b
--- /dev/null
@@ -0,0 +1,104 @@
+From 08716ab53e917eec6d51d4e53dfffbb25e0edd8e Mon Sep 17 00:00:00 2001
+From: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Date: Thu, 28 Dec 2017 19:06:20 +0300
+Subject: [PATCH 236/241] x86/mm: Set MODULES_END to 0xffffffffff000000
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+commit f5a40711fa58f1c109165a4fec6078bf2dfd2bdc upstream.
+
+Since f06bdd4001c2 ("x86/mm: Adapt MODULES_END based on fixmap section size")
+kasan_mem_to_shadow(MODULES_END) could be not aligned to a page boundary.
+
+So passing page unaligned address to kasan_populate_zero_shadow() have two
+possible effects:
+
+1) It may leave one page hole in supposed to be populated area. After commit
+  21506525fb8d ("x86/kasan/64: Teach KASAN about the cpu_entry_area") that
+  hole happens to be in the shadow covering fixmap area and leads to crash:
+
+ BUG: unable to handle kernel paging request at fffffbffffe8ee04
+ RIP: 0010:check_memory_region+0x5c/0x190
+
+ Call Trace:
+  <NMI>
+  memcpy+0x1f/0x50
+  ghes_copy_tofrom_phys+0xab/0x180
+  ghes_read_estatus+0xfb/0x280
+  ghes_notify_nmi+0x2b2/0x410
+  nmi_handle+0x115/0x2c0
+  default_do_nmi+0x57/0x110
+  do_nmi+0xf8/0x150
+  end_repeat_nmi+0x1a/0x1e
+
+Note, the crash likely disappeared after commit 92a0f81d8957, which
+changed kasan_populate_zero_shadow() call the way it was before
+commit 21506525fb8d.
+
+2) Attempt to load module near MODULES_END will fail, because
+   __vmalloc_node_range() called from kasan_module_alloc() will hit the
+   WARN_ON(!pte_none(*pte)) in the vmap_pte_range() and bail out with error.
+
+To fix this we need to make kasan_mem_to_shadow(MODULES_END) page aligned
+which means that MODULES_END should be 8*PAGE_SIZE aligned.
+
+The whole point of commit f06bdd4001c2 was to move MODULES_END down if
+NR_CPUS is big, so the cpu_entry_area takes a lot of space.
+But since 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the fixmap")
+the cpu_entry_area is no longer in fixmap, so we could just set
+MODULES_END to a fixed 8*PAGE_SIZE aligned address.
+
+Fixes: f06bdd4001c2 ("x86/mm: Adapt MODULES_END based on fixmap section size")
+Reported-by: Jakub Kicinski <kubakici@wp.pl>
+Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Thomas Garnier <thgarnie@google.com>
+Link: https://lkml.kernel.org/r/20171228160620.23818-1-aryabinin@virtuozzo.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
+---
+ Documentation/x86/x86_64/mm.txt         | 5 +----
+ arch/x86/include/asm/pgtable_64_types.h | 2 +-
+ 2 files changed, 2 insertions(+), 5 deletions(-)
+
+diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
+index ad41b3813f0a..ddd5ffd31bd0 100644
+--- a/Documentation/x86/x86_64/mm.txt
++++ b/Documentation/x86/x86_64/mm.txt
+@@ -43,7 +43,7 @@ ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
+ ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
+ ... unused hole ...
+ ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
+-ffffffffa0000000 - [fixmap start]   (~1526 MB) module mapping space
++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
+@@ -67,9 +67,6 @@ 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.
+-The module mapping space size changes based on the CONFIG requirements for the
+-following fixmap section.
+-
+ 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.
+diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
+index e8a809ee0bb6..c92bd73b1e46 100644
+--- a/arch/x86/include/asm/pgtable_64_types.h
++++ b/arch/x86/include/asm/pgtable_64_types.h
+@@ -103,7 +103,7 @@ typedef struct { pteval_t pte; } pte_t;
+ #define MODULES_VADDR         (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
+ /* The module sections ends with the start of the fixmap */
+-#define MODULES_END           __fix_to_virt(__end_of_fixed_addresses + 1)
++#define MODULES_END           _AC(0xffffffffff000000, UL)
+ #define MODULES_LEN           (MODULES_END - MODULES_VADDR)
+ #define ESPFIX_PGD_ENTRY      _AC(-2, UL)
+-- 
+2.14.2
+