Date: Tue, 17 May 2016 15:33:04 -0400 From: Kees Cook <keescook@...omium.org> To: Thomas Garnier <thgarnie@...gle.com> Cc: "H . Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...e.de>, Andy Lutomirski <luto@...nel.org>, Dmitry Vyukov <dvyukov@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>, Dan Williams <dan.j.williams@...el.com>, Stephen Smalley <sds@...ho.nsa.gov>, Kefeng Wang <wangkefeng.wang@...wei.com>, Jonathan Corbet <corbet@....net>, Matt Fleming <matt@...eblueprint.co.uk>, Toshi Kani <toshi.kani@....com>, Alexander Kuleshov <kuleshovmail@...il.com>, Alexander Popov <alpopov@...ecurity.com>, Joerg Roedel <jroedel@...e.de>, Dave Young <dyoung@...hat.com>, Baoquan He <bhe@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>, Mark Salter <msalter@...hat.com>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, "x86@...nel.org" <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, Greg Thelen <gthelen@...gle.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: [PATCH v5 0/4] x86, boot: KASLR memory randomization On Thu, May 12, 2016 at 3:28 PM, Thomas Garnier <thgarnie@...gle.com> wrote: > This is PATCH v5 for KASLR memory implementation for x86_64. The effects of this on the kernel_page_table addresses is impressive! This is working well for me, and I think everything looks clean now. I've got the series up in my tree with some fixes we discussed off-list, along with my Signed-off-by: http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=kaslr/memory Once the rest of the KASLR patches land, these should be able to go in. I think it's well documented, and as clean as these kinds of changes can get. :) -Kees > > Recent changes: > Add performance information on commit. > Add details on PUD alignment. > Add information on testing against the KASLR bypass exploit. > Rebase on next-20160511 and merge recent KASLR changes. > Integrate feedback from Kees. > > ***Background: > The current implementation of KASLR randomizes only the base address of > the kernel and its modules. Research was published showing that static > memory can be overwitten to elevate privileges bypassing KASLR. > > In more details: > > The physical memory mapping holds most allocations from boot and heap > allocators. Knowning the base address and physical memory size, an > attacker can deduce the PDE virtual address for the vDSO memory page. > This attack was demonstrated at CanSecWest 2016, in the "Getting > Physical Extreme Abuse of Intel Based Paged Systems" > https://goo.gl/ANpWdV (see second part of the presentation). The > exploits used against Linux worked successfuly against 4.6+ but fail > with KASLR memory enabled (https://goo.gl/iTtXMJ). Similar research > was done at Google leading to this patch proposal. Variants exists to > overwrite /proc or /sys objects ACLs leading to elevation of privileges. > These variants were tested against 4.6+. > > This set of patches randomizes base address and padding of three > major memory sections (physical memory mapping, vmalloc & vmemmap). > It mitigates exploits relying on predictable kernel addresses. This > feature can be enabled with the CONFIG_RANDOMIZE_MEMORY option. > > Padding for the memory hotplug support is managed by > CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING. The default value is 10 > terabytes. > > The patches were tested on qemu & physical machines. Xen compatibility was > also verified. Multiple reboots were used to verify entropy for each > memory section. > > ***Problems that needed solving: > - The three target memory sections are never at the same place between > boots. > - The physical memory mapping can use a virtual address not aligned on > the PGD page table. > - Have good entropy early at boot before get_random_bytes is available. > - Add optional padding for memory hotplug compatibility. > > ***Parts: > - The first part prepares for the KASLR memory randomization by > refactoring entropy functions used by the current implementation and > support PUD level virtual addresses for physical mapping. > (Patches 01-02) > - The second part implements the KASLR memory randomization for all > sections mentioned. > (Patch 03) > - The third part adds support for memory hotplug by adding an option to > define the padding used between the physical memory mapping section > and the others. > (Patch 04) > > Performance data: > > Kernbench shows almost no difference (-+ less than 1%): > > Before: > > Average Optimal load -j 12 Run (std deviation): > Elapsed Time 102.63 (1.2695) > User Time 1034.89 (1.18115) > System Time 87.056 (0.456416) > Percent CPU 1092.9 (13.892) > Context Switches 199805 (3455.33) > Sleeps 97907.8 (900.636) > > After: > > Average Optimal load -j 12 Run (std deviation): > Elapsed Time 102.489 (1.10636) > User Time 1034.86 (1.36053) > System Time 87.764 (0.49345) > Percent CPU 1095 (12.7715) > Context Switches 199036 (4298.1) > Sleeps 97681.6 (1031.11) > > Hackbench shows 0% difference on average (hackbench 90 > repeated 10 times): > > attemp,before,after > 1,0.076,0.069 > 2,0.072,0.069 > 3,0.066,0.066 > 4,0.066,0.068 > 5,0.066,0.067 > 6,0.066,0.069 > 7,0.067,0.066 > 8,0.063,0.067 > 9,0.067,0.065 > 10,0.068,0.071 > average,0.0677,0.0677 > > Thanks! > -- Kees Cook Chrome OS & Brillo Security
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.