Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

[Baoquan He <bhe@redhat.com>]

On 03/16/17 at 09:14am, Ingo Molnar wrote:
> 
> * Borislav Petkov <bp@suse.de> 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 <bhe@redhat.com>
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 <bhe@redhat.com>
---
 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