From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752063AbdCCPIx (ORCPT ); Fri, 3 Mar 2017 10:08:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50268 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751584AbdCCPIX (ORCPT ); Fri, 3 Mar 2017 10:08:23 -0500 Date: Fri, 3 Mar 2017 23:07:51 +0800 From: Baoquan He To: Borislav Petkov Cc: tglx@linutronix.de, hpa@zytor.com, mingo@redhat.com, linux-kernel@vger.kernel.org, x86@kernel.org, keescook@chromium.org, yinghai@kernel.org, anderson@redhat.com, luto@kernel.org, thgarnie@google.com, kuleshovmail@gmail.com Subject: Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Message-ID: <20170303150751.GH18391@x1> References: <1486040077-3719-1-git-send-email-bhe@redhat.com> <1486040077-3719-2-git-send-email-bhe@redhat.com> <20170214173217.3qtf6fhiklhgsmi5@pd.tnic> <20170226040908.GB14810@x1> <20170303114349.krl6s5qfjmwz3mrg@pd.tnic> <20170303120616.GE18391@x1> <20170303121614.7cgyb6gfhtgmcide@pd.tnic> <20170303125213.GF18391@x1> <20170303131152.GG18391@x1> <20170303142830.pkkvn2iz7dwceei6@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170303142830.pkkvn2iz7dwceei6@pd.tnic> User-Agent: Mutt/1.7.0 (2016-08-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 03 Mar 2017 15:07:55 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/03/17 at 03:28pm, Borislav Petkov wrote: > On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote: > > And another meaning of defining kernel iamge size and mapping size > > differently is we can randomize the limited kernel image in the mapping > > area. If they are the same or kernel image can be very large, the > > position will be fixed or very few, kernel text KASLR will be > > meaningless. > > This is simply not true: > > @@ -408,9 +408,9 @@ static unsigned long find_random_virt_addr(unsigned long minimum, > /* > * There are how many CONFIG_PHYSICAL_ALIGN-sized slots > * that can hold image_size within the range of minimum to > - * KERNEL_IMAGE_SIZE? > + * KERNEL_MAPPING_SIZE? > */ > - slots = (KERNEL_IMAGE_SIZE - minimum - image_size) / > + slots = (KERNEL_MAPPING_SIZE - minimum - image_size) / > CONFIG_PHYSICAL_ALIGN + 1; > > *With* kaslr, KERNEL_IMAGE_SIZE = 1G and KERNEL_MAPPING_SIZE = 1G. > Before your patch KERNEL_IMAGE_SIZE = 1G too with kaslr enabled. 512M and 1G is the first case, just an example. Usually kernel image size is only about 20M, from my laptop. Yes, before KERNEL_IMAGE_SIZE is 1G with kaslr enabled. when you suggested taking a fixed size for the KERNEL_IMAGE_SIZE, but not changed back and forth with the kaslr set or not, I started to consider this. See the 1G, hard-constrainted because of level2_kernel_pgt. In the future we could put kernel mapping area in another place to remove the 1G limitation, could be 10G or 512G since virtual address are so redundent, just an assumption, kernel KASLR can benefit from this actually, but we can't make upper value of kernel image size also be that big. That will make linker script checking lose meaning. Thanks Baoquan