Message-ID: <CAGXu5jKtbJrUd6C=4eKBZphfQkN9=GXqN=1g2rD9oEc-A_nfsw@mail.gmail.com>
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