diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-kernel/coreos-kernel-4.14.12.ebuild b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-kernel/coreos-kernel-4.14.13.ebuild similarity index 100% rename from sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-kernel/coreos-kernel-4.14.12.ebuild rename to sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-kernel/coreos-kernel-4.14.13.ebuild diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-modules/coreos-modules-4.14.12.ebuild b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-modules/coreos-modules-4.14.13.ebuild similarity index 100% rename from sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-modules/coreos-modules-4.14.12.ebuild rename to sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-modules/coreos-modules-4.14.13.ebuild diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/Manifest b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/Manifest index 9c216c54ac..cc74ee9e09 100644 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/Manifest +++ b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/Manifest @@ -1,2 +1,2 @@ DIST linux-4.14.tar.xz 100770500 SHA256 f81d59477e90a130857ce18dc02f4fbe5725854911db1e7ba770c7cd350f96a7 SHA512 77e43a02d766c3d73b7e25c4aafb2e931d6b16e870510c22cef0cdb05c3acb7952b8908ebad12b10ef982c6efbe286364b1544586e715cf38390e483927904d8 WHIRLPOOL fee10d54ecb210156aa55364ecc15867127819e9f7ff9ec5f6ef159b1013e2ae3d3a28d35c62d663886cbe826b996a1387671766093be002536309045a8e4d10 -DIST patch-4.14.12.xz 382328 SHA256 da5d8db44b0988e4c45346899d3f5a51f8bd6c25f14e729615ca9ff9f17bdefd SHA512 b11b91503c9eb879b79cb16683204f5dbb467aac62dcfc1b025f889dc38016d990c0fd1879210226430e9f9ac6e168439b13603781188d67d213b12a334b4e5b WHIRLPOOL 022c77a93dab4761872cd67610ce64ba7b86bf3fb78385181fe30a2f3f142d9463f1785be86c923e321bbdde4a703c2ba471a26d3ebcbef77e3b3453663a5908 +DIST patch-4.14.13.xz 391992 SHA256 ce897f467e80452f29d7a7a8809e8585ea12192a2c32e4d18578f64b043e802e SHA512 6ae473fbed193a2997e9d3f02ef9c1b5a1bc6f2464ef32a4bc22306659f5d978ab64e531b3488bf8266732043868f1b14183e463c17020d1dc95c8cf70343415 WHIRLPOOL 2912c2a87e30491e5c7d0dec52e560b5cb9986bdafff80299a2a6824634ad5e9f65fb4961554885f18cb8b02f2a4c836964d5c974fefd745dce74cdbd21a3057 diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/coreos-sources-4.14.12.ebuild b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/coreos-sources-4.14.13.ebuild similarity index 81% rename from sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/coreos-sources-4.14.12.ebuild rename to sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/coreos-sources-4.14.13.ebuild index 836be075a9..ab4660f54a 100644 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/coreos-sources-4.14.12.ebuild +++ b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/coreos-sources-4.14.13.ebuild @@ -46,9 +46,4 @@ UNIPATCH_LIST=" ${PATCH_DIR}/z0003-dccp-CVE-2017-8824-use-after-free-in-DCCP-code.patch \ ${PATCH_DIR}/z0004-block-factor-out-__blkdev_issue_zero_pages.patch \ ${PATCH_DIR}/z0005-block-cope-with-WRITE-ZEROES-failing-in-blkdev_issue.patch \ - ${PATCH_DIR}/z0006-x86-mm-Set-MODULES_END-to-0xffffffffff000000.patch \ - ${PATCH_DIR}/z0007-x86-mm-Map-cpu_entry_area-at-the-same-place-on-4-5-l.patch \ - ${PATCH_DIR}/z0008-x86-kaslr-Fix-the-vaddr_end-mess.patch \ - ${PATCH_DIR}/z0009-x86-events-intel-ds-Use-the-proper-cache-flush-metho.patch \ - ${PATCH_DIR}/z0010-x86-tlb-Drop-the-_GPL-from-the-cpu_tlbstate-export.patch \ " diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0001-kbuild-derive-relative-path-for-KBUILD_SRC-from-CURD.patch b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0001-kbuild-derive-relative-path-for-KBUILD_SRC-from-CURD.patch index 15178a4961..c227089e8e 100644 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0001-kbuild-derive-relative-path-for-KBUILD_SRC-from-CURD.patch +++ b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0001-kbuild-derive-relative-path-for-KBUILD_SRC-from-CURD.patch @@ -1,7 +1,7 @@ -From d32cba5030fd878d09f567916eade02006141a97 Mon Sep 17 00:00:00 2001 +From 5ffa2f55c3f79a730ebf6ef5cc30cca3309570af Mon Sep 17 00:00:00 2001 From: Vito Caputo Date: Wed, 25 Nov 2015 02:59:45 -0800 -Subject: [PATCH 01/10] kbuild: derive relative path for KBUILD_SRC from CURDIR +Subject: [PATCH 1/5] kbuild: derive relative path for KBUILD_SRC from CURDIR This enables relocating source and build trees to different roots, provided they stay reachable relative to one another. Useful for @@ -12,7 +12,7 @@ by some undesirable path component. 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile -index 20f7d4de0f1c..0c3c92caf360 100644 +index a67c5179052a..c5bf22161186 100644 --- a/Makefile +++ b/Makefile @@ -143,7 +143,8 @@ $(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: sub-make diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0002-Add-arm64-coreos-verity-hash.patch b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0002-Add-arm64-coreos-verity-hash.patch index 511a651009..1544dca9b4 100644 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0002-Add-arm64-coreos-verity-hash.patch +++ b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0002-Add-arm64-coreos-verity-hash.patch @@ -1,7 +1,7 @@ -From 9caf327dfb0a7da20e8277e135929a3ae7d73e21 Mon Sep 17 00:00:00 2001 +From 8c7e5a2443574e7e49d16aede44074c4a1527e55 Mon Sep 17 00:00:00 2001 From: Geoff Levand Date: Fri, 11 Nov 2016 17:28:52 -0800 -Subject: [PATCH 02/10] Add arm64 coreos verity hash +Subject: [PATCH 2/5] Add arm64 coreos verity hash Signed-off-by: Geoff Levand --- diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0003-dccp-CVE-2017-8824-use-after-free-in-DCCP-code.patch b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0003-dccp-CVE-2017-8824-use-after-free-in-DCCP-code.patch index 6078a83929..4b5e5a8f8b 100644 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0003-dccp-CVE-2017-8824-use-after-free-in-DCCP-code.patch +++ b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0003-dccp-CVE-2017-8824-use-after-free-in-DCCP-code.patch @@ -1,7 +1,7 @@ -From 0ad805080ae867f8af81462be7f067c4c0041eb1 Mon Sep 17 00:00:00 2001 +From 46a43d4fb04265fb137960c34dd284211ee96816 Mon Sep 17 00:00:00 2001 From: Mohamed Ghannam Date: Tue, 5 Dec 2017 12:23:04 -0800 -Subject: [PATCH 03/10] dccp: CVE-2017-8824: use-after-free in DCCP code +Subject: [PATCH 3/5] dccp: CVE-2017-8824: use-after-free in DCCP code Whenever the sock object is in DCCP_CLOSED state, dccp_disconnect() must free dccps_hc_tx_ccid and dccps_hc_rx_ccid and set to NULL. diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0004-block-factor-out-__blkdev_issue_zero_pages.patch b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0004-block-factor-out-__blkdev_issue_zero_pages.patch index 30d97c425f..c321d0725a 100644 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0004-block-factor-out-__blkdev_issue_zero_pages.patch +++ b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0004-block-factor-out-__blkdev_issue_zero_pages.patch @@ -1,7 +1,7 @@ -From 3674db0a28b9c0e585c556fdb8f14eb656894500 Mon Sep 17 00:00:00 2001 +From 42762e318ed593a9a391d254d69999e3e0f6335e Mon Sep 17 00:00:00 2001 From: Ilya Dryomov Date: Mon, 16 Oct 2017 15:59:09 +0200 -Subject: [PATCH 04/10] block: factor out __blkdev_issue_zero_pages() +Subject: [PATCH 4/5] block: factor out __blkdev_issue_zero_pages() blkdev_issue_zeroout() will use this in !BLKDEV_ZERO_NOFALLBACK case. diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0005-block-cope-with-WRITE-ZEROES-failing-in-blkdev_issue.patch b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0005-block-cope-with-WRITE-ZEROES-failing-in-blkdev_issue.patch index 969880fc0b..299f66bc27 100644 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0005-block-cope-with-WRITE-ZEROES-failing-in-blkdev_issue.patch +++ b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0005-block-cope-with-WRITE-ZEROES-failing-in-blkdev_issue.patch @@ -1,7 +1,7 @@ -From 65e2c9be0adbf3cf0a211c8f8f0530b482b0dd98 Mon Sep 17 00:00:00 2001 +From 63c515ce1b27b3b496223b058761dd9ee80d2abd Mon Sep 17 00:00:00 2001 From: Ilya Dryomov Date: Mon, 16 Oct 2017 15:59:10 +0200 -Subject: [PATCH 05/10] block: cope with WRITE ZEROES failing in +Subject: [PATCH 5/5] block: cope with WRITE ZEROES failing in blkdev_issue_zeroout() sd_config_write_same() ignores ->max_ws_blocks == 0 and resets it to diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0006-x86-mm-Set-MODULES_END-to-0xffffffffff000000.patch b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0006-x86-mm-Set-MODULES_END-to-0xffffffffff000000.patch deleted file mode 100644 index 0aadcf8544..0000000000 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0006-x86-mm-Set-MODULES_END-to-0xffffffffff000000.patch +++ /dev/null @@ -1,98 +0,0 @@ -From 75c424050cce884af639e8a32d9021e0449ad590 Mon Sep 17 00:00:00 2001 -From: Andrey Ryabinin -Date: Thu, 28 Dec 2017 19:06:20 +0300 -Subject: [PATCH 06/10] x86/mm: Set MODULES_END to 0xffffffffff000000 - -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: - - 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 -Signed-off-by: Andrey Ryabinin -Signed-off-by: Thomas Gleixner -Cc: stable@vger.kernel.org -Cc: Andy Lutomirski -Cc: Thomas Garnier -Link: https://lkml.kernel.org/r/20171228160620.23818-1-aryabinin@virtuozzo.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 b97a539bcdee..6233e5595389 100644 ---- a/arch/x86/include/asm/pgtable_64_types.h -+++ b/arch/x86/include/asm/pgtable_64_types.h -@@ -104,7 +104,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.1 - diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0007-x86-mm-Map-cpu_entry_area-at-the-same-place-on-4-5-l.patch b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0007-x86-mm-Map-cpu_entry_area-at-the-same-place-on-4-5-l.patch deleted file mode 100644 index faf6a765b5..0000000000 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0007-x86-mm-Map-cpu_entry_area-at-the-same-place-on-4-5-l.patch +++ /dev/null @@ -1,93 +0,0 @@ -From 10e74b809cc9387b3415f3bb022d8c7b6c0284b1 Mon Sep 17 00:00:00 2001 -From: Thomas Gleixner -Date: Thu, 4 Jan 2018 13:01:40 +0100 -Subject: [PATCH 07/10] x86/mm: Map cpu_entry_area at the same place on 4/5 - level - -There is no reason for 4 and 5 level pagetables to have a different -layout. It just makes determining vaddr_end for KASLR harder than -necessary. - -Fixes: 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the fixmap") -Signed-off-by: Thomas Gleixner -Cc: Andy Lutomirski -Cc: Benjamin Gilbert -Cc: Greg Kroah-Hartman -Cc: stable -Cc: Dave Hansen -Cc: Peter Zijlstra -Cc: Thomas Garnier , -Cc: Alexander Kuleshov -Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801041320360.1771@nanos ---- - Documentation/x86/x86_64/mm.txt | 7 ++++--- - arch/x86/include/asm/pgtable_64_types.h | 4 ++-- - arch/x86/mm/dump_pagetables.c | 2 +- - 3 files changed, 7 insertions(+), 6 deletions(-) - -diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt -index ddd5ffd31bd0..f7dabe1f01e9 100644 ---- a/Documentation/x86/x86_64/mm.txt -+++ b/Documentation/x86/x86_64/mm.txt -@@ -12,8 +12,8 @@ ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) - ... unused hole ... - ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB) - ... unused hole ... --fffffe0000000000 - fffffe7fffffffff (=39 bits) LDT remap for PTI --fffffe8000000000 - fffffeffffffffff (=39 bits) cpu_entry_area mapping -+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 -@@ -37,7 +37,8 @@ ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB) - ... unused hole ... - ffdf000000000000 - fffffc0000000000 (=53 bits) kasan shadow memory (8PB) - ... unused hole ... --fffffe8000000000 - fffffeffffffffff (=39 bits) cpu_entry_area mapping -+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 -diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h -index 6233e5595389..61b4b60bdc13 100644 ---- a/arch/x86/include/asm/pgtable_64_types.h -+++ b/arch/x86/include/asm/pgtable_64_types.h -@@ -88,7 +88,7 @@ typedef struct { pteval_t pte; } pte_t; - # define VMALLOC_SIZE_TB _AC(32, UL) - # define __VMALLOC_BASE _AC(0xffffc90000000000, UL) - # define __VMEMMAP_BASE _AC(0xffffea0000000000, UL) --# define LDT_PGD_ENTRY _AC(-4, UL) -+# define LDT_PGD_ENTRY _AC(-3, UL) - # define LDT_BASE_ADDR (LDT_PGD_ENTRY << PGDIR_SHIFT) - #endif - -@@ -110,7 +110,7 @@ typedef struct { pteval_t pte; } pte_t; - #define ESPFIX_PGD_ENTRY _AC(-2, UL) - #define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << P4D_SHIFT) - --#define CPU_ENTRY_AREA_PGD _AC(-3, UL) -+#define CPU_ENTRY_AREA_PGD _AC(-4, UL) - #define CPU_ENTRY_AREA_BASE (CPU_ENTRY_AREA_PGD << P4D_SHIFT) - - #define EFI_VA_START ( -4 * (_AC(1, UL) << 30)) -diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c -index f56902c1f04b..2a4849e92831 100644 ---- a/arch/x86/mm/dump_pagetables.c -+++ b/arch/x86/mm/dump_pagetables.c -@@ -61,10 +61,10 @@ enum address_markers_idx { - KASAN_SHADOW_START_NR, - KASAN_SHADOW_END_NR, - #endif -+ CPU_ENTRY_AREA_NR, - #if defined(CONFIG_MODIFY_LDT_SYSCALL) && !defined(CONFIG_X86_5LEVEL) - LDT_NR, - #endif -- CPU_ENTRY_AREA_NR, - #ifdef CONFIG_X86_ESPFIX64 - ESPFIX_START_NR, - #endif --- -2.14.1 - diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0008-x86-kaslr-Fix-the-vaddr_end-mess.patch b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0008-x86-kaslr-Fix-the-vaddr_end-mess.patch deleted file mode 100644 index 107e411d97..0000000000 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0008-x86-kaslr-Fix-the-vaddr_end-mess.patch +++ /dev/null @@ -1,138 +0,0 @@ -From b7c33e42ce3b9c7e2e1b4fa2e7c8c2206a624689 Mon Sep 17 00:00:00 2001 -From: Thomas Gleixner -Date: Thu, 4 Jan 2018 12:32:03 +0100 -Subject: [PATCH 08/10] x86/kaslr: Fix the vaddr_end mess - -vaddr_end for KASLR is only documented in the KASLR code itself and is -adjusted depending on config options. So it's not surprising that a change -of the memory layout causes KASLR to have the wrong vaddr_end. This can map -arbitrary stuff into other areas causing hard to understand problems. - -Remove the whole ifdef magic and define the start of the cpu_entry_area to -be the end of the KASLR vaddr range. - -Add documentation to that effect. - -Fixes: 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the fixmap") -Reported-by: Benjamin Gilbert -Signed-off-by: Thomas Gleixner -Tested-by: Benjamin Gilbert -Cc: Andy Lutomirski -Cc: Greg Kroah-Hartman -Cc: stable -Cc: Dave Hansen -Cc: Peter Zijlstra -Cc: Thomas Garnier , -Cc: Alexander Kuleshov -Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801041320360.1771@nanos ---- - Documentation/x86/x86_64/mm.txt | 6 ++++++ - arch/x86/include/asm/pgtable_64_types.h | 8 +++++++- - arch/x86/mm/kaslr.c | 32 +++++++++----------------------- - 3 files changed, 22 insertions(+), 24 deletions(-) - -diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt -index f7dabe1f01e9..ea91cb61a602 100644 ---- a/Documentation/x86/x86_64/mm.txt -+++ b/Documentation/x86/x86_64/mm.txt -@@ -12,6 +12,7 @@ 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 -@@ -37,6 +38,7 @@ 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 -@@ -71,3 +73,7 @@ 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. -diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h -index 61b4b60bdc13..6b8f73dcbc2c 100644 ---- a/arch/x86/include/asm/pgtable_64_types.h -+++ b/arch/x86/include/asm/pgtable_64_types.h -@@ -75,7 +75,13 @@ typedef struct { pteval_t pte; } pte_t; - #define PGDIR_SIZE (_AC(1, UL) << PGDIR_SHIFT) - #define PGDIR_MASK (~(PGDIR_SIZE - 1)) - --/* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */ -+/* -+ * See Documentation/x86/x86_64/mm.txt for a description of the memory map. -+ * -+ * 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. -+ */ - #define MAXMEM _AC(__AC(1, UL) << MAX_PHYSMEM_BITS, UL) - - #ifdef CONFIG_X86_5LEVEL -diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c -index 879ef930e2c2..aedebd2ebf1e 100644 ---- a/arch/x86/mm/kaslr.c -+++ b/arch/x86/mm/kaslr.c -@@ -34,25 +34,14 @@ - #define TB_SHIFT 40 - - /* -- * Virtual address start and end range for randomization. The end changes base -- * on configuration to have the highest amount of space for randomization. -- * It increases the possible random position for each randomized region. -+ * Virtual address start and end range for randomization. - * -- * You need to add an if/def entry if you introduce a new memory region -- * compatible with KASLR. Your entry must be in logical order with memory -- * layout. For example, ESPFIX is before EFI because its virtual address is -- * before. You also need to add a BUILD_BUG_ON() in kernel_randomize_memory() to -- * ensure that this order is correct and won't be changed. -+ * The end address could depend on more configuration options to make the -+ * highest amount of space for randomization available, but that's too hard -+ * to keep straight and caused issues already. - */ - static const unsigned long vaddr_start = __PAGE_OFFSET_BASE; -- --#if defined(CONFIG_X86_ESPFIX64) --static const unsigned long vaddr_end = ESPFIX_BASE_ADDR; --#elif defined(CONFIG_EFI) --static const unsigned long vaddr_end = EFI_VA_END; --#else --static const unsigned long vaddr_end = __START_KERNEL_map; --#endif -+static const unsigned long vaddr_end = CPU_ENTRY_AREA_BASE; - - /* Default values */ - unsigned long page_offset_base = __PAGE_OFFSET_BASE; -@@ -101,15 +90,12 @@ void __init kernel_randomize_memory(void) - unsigned long remain_entropy; - - /* -- * All these BUILD_BUG_ON checks ensures the memory layout is -- * consistent with the vaddr_start/vaddr_end variables. -+ * These BUILD_BUG_ON checks ensure the memory layout is consistent -+ * with the vaddr_start/vaddr_end variables. These checks are very -+ * limited.... - */ - BUILD_BUG_ON(vaddr_start >= vaddr_end); -- BUILD_BUG_ON(IS_ENABLED(CONFIG_X86_ESPFIX64) && -- vaddr_end >= EFI_VA_END); -- BUILD_BUG_ON((IS_ENABLED(CONFIG_X86_ESPFIX64) || -- IS_ENABLED(CONFIG_EFI)) && -- vaddr_end >= __START_KERNEL_map); -+ BUILD_BUG_ON(vaddr_end != CPU_ENTRY_AREA_BASE); - BUILD_BUG_ON(vaddr_end > __START_KERNEL_map); - - if (!kaslr_memory_enabled()) --- -2.14.1 - diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0009-x86-events-intel-ds-Use-the-proper-cache-flush-metho.patch b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0009-x86-events-intel-ds-Use-the-proper-cache-flush-metho.patch deleted file mode 100644 index 5e6fc5f1f6..0000000000 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0009-x86-events-intel-ds-Use-the-proper-cache-flush-metho.patch +++ /dev/null @@ -1,99 +0,0 @@ -From 317036bde63956361dc022ed1401ed8b0f22a682 Mon Sep 17 00:00:00 2001 -From: Peter Zijlstra -Date: Thu, 4 Jan 2018 18:07:12 +0100 -Subject: [PATCH 09/10] x86/events/intel/ds: Use the proper cache flush method - for mapping ds buffers - -Thomas reported the following warning: - - BUG: using smp_processor_id() in preemptible [00000000] code: ovsdb-server/4498 - caller is native_flush_tlb_single+0x57/0xc0 - native_flush_tlb_single+0x57/0xc0 - __set_pte_vaddr+0x2d/0x40 - set_pte_vaddr+0x2f/0x40 - cea_set_pte+0x30/0x40 - ds_update_cea.constprop.4+0x4d/0x70 - reserve_ds_buffers+0x159/0x410 - x86_reserve_hardware+0x150/0x160 - x86_pmu_event_init+0x3e/0x1f0 - perf_try_init_event+0x69/0x80 - perf_event_alloc+0x652/0x740 - SyS_perf_event_open+0x3f6/0xd60 - do_syscall_64+0x5c/0x190 - -set_pte_vaddr is used to map the ds buffers into the cpu entry area, but -there are two problems with that: - - 1) The resulting flush is not supposed to be called in preemptible context - - 2) The cpu entry area is supposed to be per CPU, but the debug store - buffers are mapped for all CPUs so these mappings need to be flushed - globally. - -Add the necessary preemption protection across the mapping code and flush -TLBs globally. - -Fixes: c1961a4631da ("x86/events/intel/ds: Map debug buffers in cpu_entry_area") -Reported-by: Thomas Zeitlhofer -Signed-off-by: Peter Zijlstra -Signed-off-by: Thomas Gleixner -Tested-by: Thomas Zeitlhofer -Cc: Greg Kroah-Hartman -Cc: Hugh Dickins -Cc: stable@vger.kernel.org -Link: https://lkml.kernel.org/r/20180104170712.GB3040@hirez.programming.kicks-ass.net ---- - arch/x86/events/intel/ds.c | 16 ++++++++++++++++ - 1 file changed, 16 insertions(+) - -diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c -index 8f0aace08b87..8156e47da7ba 100644 ---- a/arch/x86/events/intel/ds.c -+++ b/arch/x86/events/intel/ds.c -@@ -5,6 +5,7 @@ - - #include - #include -+#include - #include - - #include "../perf_event.h" -@@ -283,20 +284,35 @@ static DEFINE_PER_CPU(void *, insn_buffer); - - static void ds_update_cea(void *cea, void *addr, size_t size, pgprot_t prot) - { -+ unsigned long start = (unsigned long)cea; - phys_addr_t pa; - size_t msz = 0; - - pa = virt_to_phys(addr); -+ -+ preempt_disable(); - for (; msz < size; msz += PAGE_SIZE, pa += PAGE_SIZE, cea += PAGE_SIZE) - cea_set_pte(cea, pa, prot); -+ -+ /* -+ * This is a cross-CPU update of the cpu_entry_area, we must shoot down -+ * all TLB entries for it. -+ */ -+ flush_tlb_kernel_range(start, start + size); -+ preempt_enable(); - } - - static void ds_clear_cea(void *cea, size_t size) - { -+ unsigned long start = (unsigned long)cea; - size_t msz = 0; - -+ preempt_disable(); - for (; msz < size; msz += PAGE_SIZE, cea += PAGE_SIZE) - cea_set_pte(cea, 0, PAGE_NONE); -+ -+ flush_tlb_kernel_range(start, start + size); -+ preempt_enable(); - } - - static void *dsalloc_pages(size_t size, gfp_t flags, int cpu) --- -2.14.1 - diff --git a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0010-x86-tlb-Drop-the-_GPL-from-the-cpu_tlbstate-export.patch b/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0010-x86-tlb-Drop-the-_GPL-from-the-cpu_tlbstate-export.patch deleted file mode 100644 index d3244a156c..0000000000 --- a/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.14/z0010-x86-tlb-Drop-the-_GPL-from-the-cpu_tlbstate-export.patch +++ /dev/null @@ -1,46 +0,0 @@ -From 7f13b5ed9cf52b63f3bff4587a983b9b5dbdf3ce Mon Sep 17 00:00:00 2001 -From: Thomas Gleixner -Date: Thu, 4 Jan 2018 22:19:04 +0100 -Subject: [PATCH 10/10] x86/tlb: Drop the _GPL from the cpu_tlbstate export - -The recent changes for PTI touch cpu_tlbstate from various tlb_flush -inlines. cpu_tlbstate is exported as GPL symbol, so this causes a -regression when building the most beloved out of tree drivers for certain -graphics card. - -Aside of that the export was wrong since it was introduced as it should -have been EXPORT_PER_CPU_SYMBOL_GPL(). - -Use the correct PER_CPU export and drop the _GPL to restore the previous -state which allows users to utilize the cards they payed for. I'm always -happy to make this kind of change to support our #friends (or however this -hot hashtag is named today) from the closet sauce graphics world.. - -Fixes: 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4") -Fixes: 6fd166aae78c ("x86/mm: Use/Fix PCID to optimize user/kernel switches") -Reported-by: Kees Cook -Signed-off-by: Thomas Gleixner -Cc: Greg Kroah-Hartman -Cc: Peter Zijlstra -Cc: Andy Lutomirski -Cc: stable@vger.kernel.org ---- - arch/x86/mm/init.c | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c -index 80259ad8c386..6b462a472a7b 100644 ---- a/arch/x86/mm/init.c -+++ b/arch/x86/mm/init.c -@@ -870,7 +870,7 @@ __visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tlb_state, cpu_tlbstate) = { - .next_asid = 1, - .cr4 = ~0UL, /* fail hard if we screw up cr4 shadow initialization */ - }; --EXPORT_SYMBOL_GPL(cpu_tlbstate); -+EXPORT_PER_CPU_SYMBOL(cpu_tlbstate); - - void update_cache_mode_entry(unsigned entry, enum page_cache_mode cache) - { --- -2.14.1 -