linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Garnier <thgarnie@google.com>
To: "H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@suse.de>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Garnier <thgarnie@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Kees Cook <keescook@chromium.org>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Seth Jennings <sjennings@variantweb.net>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Toshi Kani <toshi.kani@hpe.com>,
	Alexander Kuleshov <kuleshovmail@gmail.com>,
	Alexander Popov <alpopov@ptsecurity.com>,
	Joerg Roedel <jroedel@suse.de>, Dave Young <dyoung@redhat.com>,
	Baoquan He <bhe@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Mark Salter <msalter@redhat.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, gthelen@google.com,
	kernel-hardening@lists.openwall.com
Subject: [RFC v1 0/4] x86, boot: KASLR memory implementation (x86_64)
Date: Fri, 15 Apr 2016 15:03:09 -0700	[thread overview]
Message-ID: <1460757793-59020-1-git-send-email-thgarnie@google.com> (raw)

This is RFC v1 for KASLR memory implementation on x86_64. It was reviewed
early by Kees Cook.

***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.

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!

Thomas

             reply	other threads:[~2016-04-15 22:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-15 22:03 Thomas Garnier [this message]
2016-04-15 22:03 ` [RFC v1 1/4] x86, boot: Refactor KASLR entropy functions Thomas Garnier
2016-04-15 22:03 ` [RFC v1 2/4] x86, boot: PUD VA support for physical mapping (x86_64) Thomas Garnier
2016-04-15 22:03 ` [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64) Thomas Garnier
2016-04-18 14:46   ` Joerg Roedel
2016-04-18 14:56     ` Thomas Garnier
2016-04-18 19:01     ` H. Peter Anvin
2016-04-19 14:27   ` Joerg Roedel
2016-04-19 15:49     ` Thomas Garnier
2016-04-21 13:30   ` Boris Ostrovsky
2016-04-21 15:11     ` Thomas Garnier
2016-04-21 15:46     ` H. Peter Anvin
2016-04-21 15:52       ` Thomas Garnier
2016-04-21 20:15         ` H. Peter Anvin
2016-04-21 20:18           ` Thomas Garnier
2016-06-17  9:07   ` Ingo Molnar
2016-06-17  9:35     ` Ingo Molnar
2016-06-17  9:40     ` Ingo Molnar
2016-04-15 22:03 ` [RFC v1 4/4] x86, boot: Memory hotplug support for KASLR memory randomization Thomas Garnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1460757793-59020-1-git-send-email-thgarnie@google.com \
    --to=thgarnie@google.com \
    --cc=alpopov@ptsecurity.com \
    --cc=bhe@redhat.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@suse.de \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=dyoung@redhat.com \
    --cc=gthelen@google.com \
    --cc=hpa@zytor.com \
    --cc=jroedel@suse.de \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kuleshovmail@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@redhat.com \
    --cc=msalter@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --cc=sjennings@variantweb.net \
    --cc=tglx@linutronix.de \
    --cc=toshi.kani@hpe.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).