Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 29 Apr 2016 09:42:53 -0700
From: Thomas Garnier <>
To: "H . Peter Anvin" <>, Thomas Gleixner <>, Ingo Molnar <>, 
	Borislav Petkov <>, Andy Lutomirski <>, Thomas Garnier <>, 
	Dmitry Vyukov <>, Paolo Bonzini <>, 
	Dan Williams <>, Kees Cook <>, 
	Stephen Smalley <>, Kefeng Wang <>, 
	Jonathan Corbet <>, Matt Fleming <>, 
	Toshi Kani <>, Alexander Kuleshov <>, 
	Alexander Popov <>, Joerg Roedel <>, Dave Young <>, 
	Baoquan He <>, Dave Hansen <>, 
	Mark Salter <>, Boris Ostrovsky <>
Cc:, LKML <>,, 
	Greg Thelen <>,
Subject: Re: [PATCH 0/4] x86, boot: KASLR memory randomization

Any feedback on this patch proposal?


On Mon, Apr 25, 2016 at 9:39 AM, Thomas Garnier <> 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"
> (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
> 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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.