From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752549AbcD2Qm4 (ORCPT ); Fri, 29 Apr 2016 12:42:56 -0400 Received: from mail-yw0-f173.google.com ([209.85.161.173]:36034 "EHLO mail-yw0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752265AbcD2Qmy (ORCPT ); Fri, 29 Apr 2016 12:42:54 -0400 MIME-Version: 1.0 In-Reply-To: <1461602385-69944-1-git-send-email-thgarnie@google.com> References: <1461602385-69944-1-git-send-email-thgarnie@google.com> Date: Fri, 29 Apr 2016 09:42:53 -0700 Message-ID: Subject: Re: [PATCH 0/4] x86, boot: KASLR memory randomization 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: x86@kernel.org, LKML , linux-doc@vger.kernel.org, Greg Thelen , kernel-hardening@lists.openwall.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Any feedback on this patch proposal? Thanks, Thomas 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" > 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! > From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: <1461602385-69944-1-git-send-email-thgarnie@google.com> References: <1461602385-69944-1-git-send-email-thgarnie@google.com> Date: Fri, 29 Apr 2016 09:42:53 -0700 Message-ID: From: Thomas Garnier Content-Type: text/plain; charset=UTF-8 Subject: [kernel-hardening] Re: [PATCH 0/4] x86, boot: KASLR memory randomization 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: x86@kernel.org, LKML , linux-doc@vger.kernel.org, Greg Thelen , kernel-hardening@lists.openwall.com List-ID: Any feedback on this patch proposal? Thanks, Thomas 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" > 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! >