Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752486AbcDUUSv (ORCPT ); Thu, 21 Apr 2016 16:18:51 -0400 Received: from mail-oi0-f47.google.com ([209.85.218.47]:35447 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752261AbcDUUSt (ORCPT ); Thu, 21 Apr 2016 16:18:49 -0400 MIME-Version: 1.0 In-Reply-To: References: <1460757793-59020-1-git-send-email-thgarnie@google.com> <1460757793-59020-4-git-send-email-thgarnie@google.com> <5718D5F0.8010501@oracle.com> <9AF9DCC7-8FC4-4A93-B75A-C07B8CD9023A@zytor.com> Date: Thu, 21 Apr 2016 13:18:48 -0700 Message-ID: Subject: Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64) From: Thomas Garnier To: "H. Peter Anvin" Cc: Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Dmitry Vyukov , Paolo Bonzini , Dan Williams , Kees Cook , Stephen Smalley , Seth Jennings , Kefeng Wang , Jonathan Corbet , Matt Fleming , Toshi Kani , Alexander Kuleshov , Alexander Popov , Joerg Roedel , Dave Young , Baoquan He , Dave Hansen , Mark Salter , 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 Content-Length: 2152 Lines: 55 Make sense, thanks for the details. On Thu, Apr 21, 2016 at 1:15 PM, H. Peter Anvin wrote: > On April 21, 2016 8:52:01 AM PDT, Thomas Garnier wrote: >>On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: >>> On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky >> wrote: >>>> >>>> >>>>On 04/15/2016 06:03 PM, Thomas Garnier wrote: >>>>> +void __init kernel_randomize_memory(void) >>>>> +{ >>>>> + size_t i; >>>>> + unsigned long addr = memory_rand_start; >>>>> + unsigned long padding, rand, mem_tb; >>>>> + struct rnd_state rnd_st; >>>>> + unsigned long remain_padding = memory_rand_end - >>memory_rand_start; >>>>> + >>>>> + if (!kaslr_enabled()) >>>>> + return; >>>>> + >>>>> + /* Take the additional space when Xen is not active. */ >>>>> + if (!xen_domain()) >>>>> + page_offset_base -= __XEN_SPACE; >>>> >>>>This should be !xen_pv_domain(). Xen HVM guests are no different from >>>>bare metal as far as address ranges are concerned. (Technically it's >>>>probably !xen_pv_domain() && !xen_pvh_domain() but we can ignore PVH >>>>for >>>>now since it is being replaced by an HVM-type guest) >>>> >>>>Having said that, I am not sure I understand why page_offset_base is >>>>shifted. I thought 0xffff800000000000 - 0xffff87ffffffffff is not >>>>supposed to be used by anyone, whether we are running under a >>>>hypervisor >>>>or not. >>>> >>>>-boris >>> >>> That range is reserved for the hypervisor use. >> >>I know, I thought I could use it if no hypervisor was used but might >>introduce problems in the future so I will remove it for the next >>iteration. >> >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse brevity and >>formatting. > > At least in theory the hypervisor can use it even though no PV architecture is advertised to the kernel. One kind of would hope none would. > > I think this range is also used by the kernel pointer checking thing, as it *has* to live right next to the canonical boundary. > -- > Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.