| 1 |
From f5a40711fa58f1c109165a4fec6078bf2dfd2bdc Mon Sep 17 00:00:00 2001 |
| 2 |
From: Andrey Ryabinin <aryabinin@virtuozzo.com> |
| 3 |
Date: Thu, 28 Dec 2017 19:06:20 +0300 |
| 4 |
Subject: x86/mm: Set MODULES_END to 0xffffffffff000000 |
| 5 |
|
| 6 |
From: Andrey Ryabinin <aryabinin@virtuozzo.com> |
| 7 |
|
| 8 |
commit f5a40711fa58f1c109165a4fec6078bf2dfd2bdc upstream. |
| 9 |
|
| 10 |
Since f06bdd4001c2 ("x86/mm: Adapt MODULES_END based on fixmap section size") |
| 11 |
kasan_mem_to_shadow(MODULES_END) could be not aligned to a page boundary. |
| 12 |
|
| 13 |
So passing page unaligned address to kasan_populate_zero_shadow() have two |
| 14 |
possible effects: |
| 15 |
|
| 16 |
1) It may leave one page hole in supposed to be populated area. After commit |
| 17 |
21506525fb8d ("x86/kasan/64: Teach KASAN about the cpu_entry_area") that |
| 18 |
hole happens to be in the shadow covering fixmap area and leads to crash: |
| 19 |
|
| 20 |
BUG: unable to handle kernel paging request at fffffbffffe8ee04 |
| 21 |
RIP: 0010:check_memory_region+0x5c/0x190 |
| 22 |
|
| 23 |
Call Trace: |
| 24 |
<NMI> |
| 25 |
memcpy+0x1f/0x50 |
| 26 |
ghes_copy_tofrom_phys+0xab/0x180 |
| 27 |
ghes_read_estatus+0xfb/0x280 |
| 28 |
ghes_notify_nmi+0x2b2/0x410 |
| 29 |
nmi_handle+0x115/0x2c0 |
| 30 |
default_do_nmi+0x57/0x110 |
| 31 |
do_nmi+0xf8/0x150 |
| 32 |
end_repeat_nmi+0x1a/0x1e |
| 33 |
|
| 34 |
Note, the crash likely disappeared after commit 92a0f81d8957, which |
| 35 |
changed kasan_populate_zero_shadow() call the way it was before |
| 36 |
commit 21506525fb8d. |
| 37 |
|
| 38 |
2) Attempt to load module near MODULES_END will fail, because |
| 39 |
__vmalloc_node_range() called from kasan_module_alloc() will hit the |
| 40 |
WARN_ON(!pte_none(*pte)) in the vmap_pte_range() and bail out with error. |
| 41 |
|
| 42 |
To fix this we need to make kasan_mem_to_shadow(MODULES_END) page aligned |
| 43 |
which means that MODULES_END should be 8*PAGE_SIZE aligned. |
| 44 |
|
| 45 |
The whole point of commit f06bdd4001c2 was to move MODULES_END down if |
| 46 |
NR_CPUS is big, so the cpu_entry_area takes a lot of space. |
| 47 |
But since 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the fixmap") |
| 48 |
the cpu_entry_area is no longer in fixmap, so we could just set |
| 49 |
MODULES_END to a fixed 8*PAGE_SIZE aligned address. |
| 50 |
|
| 51 |
Fixes: f06bdd4001c2 ("x86/mm: Adapt MODULES_END based on fixmap section size") |
| 52 |
Reported-by: Jakub Kicinski <kubakici@wp.pl> |
| 53 |
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> |
| 54 |
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> |
| 55 |
Cc: Andy Lutomirski <luto@kernel.org> |
| 56 |
Cc: Thomas Garnier <thgarnie@google.com> |
| 57 |
Link: https://lkml.kernel.org/r/20171228160620.23818-1-aryabinin@virtuozzo.com |
| 58 |
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| 59 |
|
| 60 |
--- |
| 61 |
Documentation/x86/x86_64/mm.txt | 5 +---- |
| 62 |
arch/x86/include/asm/pgtable_64_types.h | 2 +- |
| 63 |
2 files changed, 2 insertions(+), 5 deletions(-) |
| 64 |
|
| 65 |
--- a/Documentation/x86/x86_64/mm.txt |
| 66 |
+++ b/Documentation/x86/x86_64/mm.txt |
| 67 |
@@ -43,7 +43,7 @@ ffffff0000000000 - ffffff7fffffffff (=39 |
| 68 |
ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space |
| 69 |
... unused hole ... |
| 70 |
ffffffff80000000 - ffffffff9fffffff (=512 MB) kernel text mapping, from phys 0 |
| 71 |
-ffffffffa0000000 - [fixmap start] (~1526 MB) module mapping space |
| 72 |
+ffffffffa0000000 - fffffffffeffffff (1520 MB) module mapping space |
| 73 |
[fixmap start] - ffffffffff5fffff kernel-internal fixmap range |
| 74 |
ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI |
| 75 |
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole |
| 76 |
@@ -67,9 +67,6 @@ memory window (this size is arbitrary, i |
| 77 |
The mappings are not part of any other kernel PGD and are only available |
| 78 |
during EFI runtime calls. |
| 79 |
|
| 80 |
-The module mapping space size changes based on the CONFIG requirements for the |
| 81 |
-following fixmap section. |
| 82 |
- |
| 83 |
Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all |
| 84 |
physical memory, vmalloc/ioremap space and virtual memory map are randomized. |
| 85 |
Their order is preserved but their base will be offset early at boot time. |
| 86 |
--- a/arch/x86/include/asm/pgtable_64_types.h |
| 87 |
+++ b/arch/x86/include/asm/pgtable_64_types.h |
| 88 |
@@ -104,7 +104,7 @@ typedef struct { pteval_t pte; } pte_t; |
| 89 |
|
| 90 |
#define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE) |
| 91 |
/* The module sections ends with the start of the fixmap */ |
| 92 |
-#define MODULES_END __fix_to_virt(__end_of_fixed_addresses + 1) |
| 93 |
+#define MODULES_END _AC(0xffffffffff000000, UL) |
| 94 |
#define MODULES_LEN (MODULES_END - MODULES_VADDR) |
| 95 |
|
| 96 |
#define ESPFIX_PGD_ENTRY _AC(-2, UL) |
Parent Directory
| 
Revision Log