From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751864AbdCPJpw (ORCPT ); Thu, 16 Mar 2017 05:45:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42182 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751357AbdCPJpu (ORCPT ); Thu, 16 Mar 2017 05:45:50 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com ECF33C04B30E Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bhe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com ECF33C04B30E Date: Thu, 16 Mar 2017 17:44:35 +0800 From: Baoquan He To: Ingo Molnar Cc: Borislav Petkov , 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: <20170316094435.GA23625@x1> References: <20170303114349.krl6s5qfjmwz3mrg@pd.tnic> <20170303120616.GE18391@x1> <20170303121614.7cgyb6gfhtgmcide@pd.tnic> <20170303125213.GF18391@x1> <20170303131152.GG18391@x1> <20170303142830.pkkvn2iz7dwceei6@pd.tnic> <20170303150751.GH18391@x1> <20170303150857.GI18391@x1> <20170303152319.yensbclmz6uomoyy@pd.tnic> <20170316081429.GA28585@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170316081429.GA28585@gmail.com> 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.31]); Thu, 16 Mar 2017 09:44:41 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/16/17 at 09:14am, Ingo Molnar wrote: > > * Borislav Petkov wrote: > > So what I'd do is keep KERNEL_IMAGE_SIZE and make it default 1G and use it > > everywhere. > > > > Then, define a separate define which is used only in vmlinux.lds.S to > > enforce the size check. Having MAPPING_SIZE and IMAGE_SIZE is just > > needlessly confusing. > > That sounds like the right solution to me - having two values is asking for > trouble. Thanks for your suggestion. OK, I will repost with only changing KERNEL_IMAGE_SIZE to 1G, just like CONFIG_RANDOMIZE_BASE is enabled in old code. I made one but haven't tested it yet, do you think it's OK? >>From eb8ab3e0c1cbe364dbd1d59cc1875a2728df700c Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Thu, 16 Mar 2017 16:36:33 +0800 Subject: [PATCH] x86/64/KASLR: Change KERNEL_IMAGE_SIZE to 1G unconditionally The current KASLR changes KERNEL_IMAGE_SIZE from 512M to 1G as long as CONFIG_RANDOMIZE_BASE is enabled, though "nokaslr" kernel option is added. This is buggy. When people specify "nokaslr", whether KASLR code compiled in or not, they expect to see no KASLR change at all, including the default limit size of kernel image and size of module space. Kees explained the only reason he made KERNEL_IMAGE_SIZE as an option was for kernel module space. It wasn't clear at the time if enough space remained for modules in all use-cases. Boris suggested we can make KERNEL_IMAGE_SIZE 1G unconditionally since practically kaslr will be enabled on the majority of the systems anyway, so we will have 1G KERNEL_IMAGE_SIZE on most. And he further pointed out that: [Quote his words as follows] """"" Realistically, on a typical bigger machine, the modules take up something like <10M: $ lsmod | awk '{ sum +=$2 } END { print sum }' 7188480 so I'm not really worried if we reduce it by default to 1G. Besides, the reduction has been there for a while now - since CONFIG_RANDOMIZE_BASE - so we probably would've heard complaints already... """"" Hence in this patch change KERNEL_IMAGE_SIZE to 1G as suggested. Signed-off-by: Baoquan He --- arch/x86/include/asm/page_64_types.h | 10 ++-------- arch/x86/kernel/head_64.S | 5 ++--- 2 files changed, 4 insertions(+), 11 deletions(-) diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h index 9215e05..98bf5a0 100644 --- a/arch/x86/include/asm/page_64_types.h +++ b/arch/x86/include/asm/page_64_types.h @@ -51,15 +51,9 @@ /* * Kernel image size is limited to 1GiB due to the fixmap living in the - * next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S). Use - * 512MiB by default, leaving 1.5GiB for modules once the page tables - * are fully set up. If kernel ASLR is configured, it can extend the - * kernel page table mapping, reducing the size of the modules area. + * next 1GiB (see level2_kernel_pgt in arch/x86/kernel/head_64.S). Leaving + * 1GiB for modules once the page tables are fully set up. */ -#if defined(CONFIG_RANDOMIZE_BASE) #define KERNEL_IMAGE_SIZE (1024 * 1024 * 1024) -#else -#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024) -#endif #endif /* _ASM_X86_PAGE_64_DEFS_H */ diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index b467b14..1e98617 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -458,12 +458,11 @@ NEXT_PAGE(level3_kernel_pgt) NEXT_PAGE(level2_kernel_pgt) /* - * 512 MB kernel mapping. We spend a full page on this pagetable - * anyway. + * 1GiB kernel mapping. We spend a full page on this pagetable. * * The kernel code+data+bss must not be bigger than that. * - * (NOTE: at +512MB starts the module area, see MODULES_VADDR. + * (NOTE: at +1GiB starts the module area, see MODULES_VADDR. * If you want to increase this then increase MODULES_VADDR * too.) */ -- 2.5.5