[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJcbSZGEMX_k0yzUfgXPmRsua4Dsp2XybxnaKxJ6Xwm1KxpaaQ@mail.gmail.com>
Date: Fri, 29 Apr 2016 09:42:53 -0700
From: Thomas Garnier <thgarnie@...gle.com>
To: "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>, Thomas Garnier <thgarnie@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>,
Dan Williams <dan.j.williams@...el.com>, Kees Cook <keescook@...omium.org>,
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>
Cc: x86@...nel.org, LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
Greg Thelen <gthelen@...gle.com>, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 0/4] x86, boot: KASLR memory randomization
Any feedback on this patch proposal?
Thanks,
Thomas
On Mon, Apr 25, 2016 at 9:39 AM, Thomas Garnier <thgarnie@...gle.com> wrote:
> This is PATCH v1 for KASLR memory implementation on x86_64. Minor changes
> were done based on RFC v1 comments.
>
> ***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). 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)
>
> Thanks!
>
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.
