From 740d45aea326d621f0098d1fab6ed3f0920f2259 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 13 Jan 2015 14:34:08 -0800 Subject: [PATCH] 3.14-stable patches added patches: kvm-x86-drop-severity-of-generation-wraparound-message.patch x86_64-vdso-fix-the-vdso-address-randomization-algorithm.patch --- ...ity-of-generation-wraparound-message.patch | 31 +++++ queue-3.14/series | 2 + ...vdso-address-randomization-algorithm.patch | 124 ++++++++++++++++++ 3 files changed, 157 insertions(+) create mode 100644 queue-3.14/kvm-x86-drop-severity-of-generation-wraparound-message.patch create mode 100644 queue-3.14/x86_64-vdso-fix-the-vdso-address-randomization-algorithm.patch diff --git a/queue-3.14/kvm-x86-drop-severity-of-generation-wraparound-message.patch b/queue-3.14/kvm-x86-drop-severity-of-generation-wraparound-message.patch new file mode 100644 index 00000000000..607c801926c --- /dev/null +++ b/queue-3.14/kvm-x86-drop-severity-of-generation-wraparound-message.patch @@ -0,0 +1,31 @@ +From a629df7eadffb03e6ce4a8616e62ea29fdf69b6b Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Mon, 22 Dec 2014 10:43:39 +0100 +Subject: kvm: x86: drop severity of "generation wraparound" message + +From: Paolo Bonzini + +commit a629df7eadffb03e6ce4a8616e62ea29fdf69b6b upstream. + +Since most virtual machines raise this message once, it is a bit annoying. +Make it KERN_DEBUG severity. + +Fixes: 7a2e8aaf0f6873b47bc2347f216ea5b0e4c258ab +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/mmu.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/mmu.c ++++ b/arch/x86/kvm/mmu.c +@@ -4384,7 +4384,7 @@ void kvm_mmu_invalidate_mmio_sptes(struc + * zap all shadow pages. + */ + if (unlikely(kvm_current_mmio_generation(kvm) == 0)) { +- printk_ratelimited(KERN_INFO "kvm: zapping shadow pages for mmio generation wraparound\n"); ++ printk_ratelimited(KERN_DEBUG "kvm: zapping shadow pages for mmio generation wraparound\n"); + kvm_mmu_invalidate_zap_all_pages(kvm); + } + } diff --git a/queue-3.14/series b/queue-3.14/series index 79d609a2095..e7a5c07b01f 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -31,3 +31,5 @@ hid-i2c-hid-prevent-buffer-overflow-in-early-irq.patch hid-roccat-potential-out-of-bounds-in-pyra_sysfs_write_settings.patch hid-add-battery-quirk-for-usb_device_id_apple_alu_wireless_2011_iso-keyboard.patch hid-add-a-new-id-0x501a-for-genius-mousepen-i608x.patch +kvm-x86-drop-severity-of-generation-wraparound-message.patch +x86_64-vdso-fix-the-vdso-address-randomization-algorithm.patch diff --git a/queue-3.14/x86_64-vdso-fix-the-vdso-address-randomization-algorithm.patch b/queue-3.14/x86_64-vdso-fix-the-vdso-address-randomization-algorithm.patch new file mode 100644 index 00000000000..5f09d4e2db0 --- /dev/null +++ b/queue-3.14/x86_64-vdso-fix-the-vdso-address-randomization-algorithm.patch @@ -0,0 +1,124 @@ +From 394f56fe480140877304d342dec46d50dc823d46 Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Fri, 19 Dec 2014 16:04:11 -0800 +Subject: x86_64, vdso: Fix the vdso address randomization algorithm + +From: Andy Lutomirski + +commit 394f56fe480140877304d342dec46d50dc823d46 upstream. + +The theory behind vdso randomization is that it's mapped at a random +offset above the top of the stack. To avoid wasting a page of +memory for an extra page table, the vdso isn't supposed to extend +past the lowest PMD into which it can fit. Other than that, the +address should be a uniformly distributed address that meets all of +the alignment requirements. + +The current algorithm is buggy: the vdso has about a 50% probability +of being at the very end of a PMD. The current algorithm also has a +decent chance of failing outright due to incorrect handling of the +case where the top of the stack is near the top of its PMD. + +This fixes the implementation. The paxtest estimate of vdso +"randomisation" improves from 11 bits to 18 bits. (Disclaimer: I +don't know what the paxtest code is actually calculating.) + +It's worth noting that this algorithm is inherently biased: the vdso +is more likely to end up near the end of its PMD than near the +beginning. Ideally we would either nix the PMD sharing requirement +or jointly randomize the vdso and the stack to reduce the bias. + +In the mean time, this is a considerable improvement with basically +no risk of compatibility issues, since the allowed outputs of the +algorithm are unchanged. + +As an easy test, doing this: + +for i in `seq 10000` + do grep -P vdso /proc/self/maps |cut -d- -f1 +done |sort |uniq -d + +used to produce lots of output (1445 lines on my most recent run). +A tiny subset looks like this: + +7fffdfffe000 +7fffe01fe000 +7fffe05fe000 +7fffe07fe000 +7fffe09fe000 +7fffe0bfe000 +7fffe0dfe000 + +Note the suspicious fe000 endings. With the fix, I get a much more +palatable 76 repeated addresses. + +Reviewed-by: Kees Cook +Signed-off-by: Andy Lutomirski +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/vdso/vma.c | 43 +++++++++++++++++++++++++++++-------------- + 1 file changed, 29 insertions(+), 14 deletions(-) + +--- a/arch/x86/vdso/vma.c ++++ b/arch/x86/vdso/vma.c +@@ -117,30 +117,45 @@ subsys_initcall(init_vdso); + + struct linux_binprm; + +-/* Put the vdso above the (randomized) stack with another randomized offset. +- This way there is no hole in the middle of address space. +- To save memory make sure it is still in the same PTE as the stack top. +- This doesn't give that many random bits */ ++/* ++ * Put the vdso above the (randomized) stack with another randomized ++ * offset. This way there is no hole in the middle of address space. ++ * To save memory make sure it is still in the same PTE as the stack ++ * top. This doesn't give that many random bits. ++ * ++ * Note that this algorithm is imperfect: the distribution of the vdso ++ * start address within a PMD is biased toward the end. ++ * ++ * Only used for the 64-bit and x32 vdsos. ++ */ + static unsigned long vdso_addr(unsigned long start, unsigned len) + { + unsigned long addr, end; + unsigned offset; +- end = (start + PMD_SIZE - 1) & PMD_MASK; ++ ++ /* ++ * Round up the start address. It can start out unaligned as a result ++ * of stack start randomization. ++ */ ++ start = PAGE_ALIGN(start); ++ ++ /* Round the lowest possible end address up to a PMD boundary. */ ++ end = (start + len + PMD_SIZE - 1) & PMD_MASK; + if (end >= TASK_SIZE_MAX) + end = TASK_SIZE_MAX; + end -= len; +- /* This loses some more bits than a modulo, but is cheaper */ +- offset = get_random_int() & (PTRS_PER_PTE - 1); +- addr = start + (offset << PAGE_SHIFT); +- if (addr >= end) +- addr = end; ++ ++ if (end > start) { ++ offset = get_random_int() % (((end - start) >> PAGE_SHIFT) + 1); ++ addr = start + (offset << PAGE_SHIFT); ++ } else { ++ addr = start; ++ } + + /* +- * page-align it here so that get_unmapped_area doesn't +- * align it wrongfully again to the next page. addr can come in 4K +- * unaligned here as a result of stack start randomization. ++ * Forcibly align the final address in case we have a hardware ++ * issue that requires alignment for performance reasons. + */ +- addr = PAGE_ALIGN(addr); + addr = align_vdso_addr(addr); + + return addr; -- 2.47.3