Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752021AbcDUUQe (ORCPT ); Thu, 21 Apr 2016 16:16:34 -0400 Received: from terminus.zytor.com ([198.137.202.10]:47668 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751041AbcDUUQd (ORCPT ); Thu, 21 Apr 2016 16:16:33 -0400 User-Agent: K-9 Mail for Android 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> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64) From: "H. Peter Anvin" Date: Thu, 21 Apr 2016 13:15:34 -0700 To: Thomas Garnier 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 Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1988 Lines: 52 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.