Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1383736 > unrolled thread

[PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET

Started byKees Cook <keescook@chromium.org>
First post2016-04-20 23:00 +0200
Last post2016-04-22 11:50 +0200
Articles 6 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET Kees Cook <keescook@chromium.org> - 2016-04-20 23:00 +0200
    Re: [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET Borislav Petkov <bp@suse.de> - 2016-04-21 19:50 +0200
      Re: [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET Kees Cook <keescook@chromium.org> - 2016-04-21 20:20 +0200
        Re: [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET Ingo Molnar <mingo@kernel.org> - 2016-04-22 09:20 +0200
          Re: [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET Borislav Petkov <bp@suse.de> - 2016-04-22 11:50 +0200
    [tip:x86/boot] x86/KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET tip-bot for Baoquan He <tipbot@zytor.com> - 2016-04-22 11:50 +0200

#1383736 — [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET

FromKees Cook <keescook@chromium.org>
Date2016-04-20 23:00 +0200
Subject[PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET
Message-ID<rq7o5-5F5-1@gated-at.bofh.it>
From: Baoquan He <bhe@redhat.com>

Currently CONFIG_RANDOMIZE_BASE_MAX_OFFSET is used to limit the maximum
offset for kernel randomization. This limit doesn't need to be a CONFIG
since it is tied completely to KERNEL_IMAGE_SIZE, and will make no sense
once physical and virtual offsets are randomized separately. This patch
removes CONFIG_RANDOMIZE_BASE_MAX_OFFSET and consolidates the Kconfig
help text.

Signed-off-by: Baoquan He <bhe@redhat.com>
[kees: rewrote changelog, dropped KERNEL_IMAGE_SIZE_DEFAULT, rewrote help]
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/Kconfig                     | 72 ++++++++++++++----------------------
 arch/x86/boot/compressed/kaslr.c     | 12 +++---
 arch/x86/include/asm/page_64_types.h |  8 ++--
 arch/x86/mm/init_32.c                |  3 --
 4 files changed, 36 insertions(+), 59 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2dc18605831f..5892d549596d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1932,54 +1932,38 @@ config RELOCATABLE
 	  (CONFIG_PHYSICAL_START) is used as the minimum location.
 
 config RANDOMIZE_BASE
-	bool "Randomize the address of the kernel image"
+	bool "Randomize the address of the kernel image (KASLR)"
 	depends on RELOCATABLE
 	default n
 	---help---
-	   Randomizes the physical and virtual address at which the
-	   kernel image is decompressed, as a security feature that
-	   deters exploit attempts relying on knowledge of the location
-	   of kernel internals.
+	  In support of Kernel Address Space Layout Randomization (KASLR),
+	  this randomizes the physical address at which the kernel image
+	  is decompressed and the virtual address where the kernel
+	  image is mapped, as a security feature that deters exploit
+	  attempts relying on knowledge of the location of kernel
+	  code internals.
+
+	  The kernel physical and virtual address can be randomized
+	  from 16MB up to 1GB on 64-bit and 512MB on 32-bit. (Note that
+	  using RANDOMIZE_BASE reduces the memory space available to
+	  kernel modules from 1.5GB to 1GB.)
+
+	  Entropy is generated using the RDRAND instruction if it is
+	  supported. If RDTSC is supported, its value is mixed into
+	  the entropy pool as well. If neither RDRAND nor RDTSC are
+	  supported, then entropy is read from the i8254 timer.
+
+	  Since the kernel is built using 2GB addressing, and
+	  PHYSICAL_ALIGN must be at a minimum of 2MB, only 10 bits of
+	  entropy is theoretically possible. Currently, with the
+	  default value for PHYSICAL_ALIGN and due to page table
+	  layouts, 64-bit uses 9 bits of entropy and 32-bit uses 8 bits.
+
+	  If CONFIG_HIBERNATE is also enabled, KASLR is disabled at boot
+	  time. To enable it, boot with "kaslr" on the kernel command
+	  line (which will also disable hibernation).
 
-	   Entropy is generated using the RDRAND instruction if it is
-	   supported. If RDTSC is supported, it is used as well. If
-	   neither RDRAND nor RDTSC are supported, then randomness is
-	   read from the i8254 timer.
-
-	   The kernel will be offset by up to RANDOMIZE_BASE_MAX_OFFSET,
-	   and aligned according to PHYSICAL_ALIGN. Since the kernel is
-	   built using 2GiB addressing, and PHYSICAL_ALGIN must be at a
-	   minimum of 2MiB, only 10 bits of entropy is theoretically
-	   possible. At best, due to page table layouts, 64-bit can use
-	   9 bits of entropy and 32-bit uses 8 bits.
-
-	   If unsure, say N.
-
-config RANDOMIZE_BASE_MAX_OFFSET
-	hex "Maximum kASLR offset allowed" if EXPERT
-	depends on RANDOMIZE_BASE
-	range 0x0 0x20000000 if X86_32
-	default "0x20000000" if X86_32
-	range 0x0 0x40000000 if X86_64
-	default "0x40000000" if X86_64
-	---help---
-	  The lesser of RANDOMIZE_BASE_MAX_OFFSET and available physical
-	  memory is used to determine the maximal offset in bytes that will
-	  be applied to the kernel when kernel Address Space Layout
-	  Randomization (kASLR) is active. This must be a multiple of
-	  PHYSICAL_ALIGN.
-
-	  On 32-bit this is limited to 512MiB by page table layouts. The
-	  default is 512MiB.
-
-	  On 64-bit this is limited by how the kernel fixmap page table is
-	  positioned, so this cannot be larger than 1GiB currently. Without
-	  RANDOMIZE_BASE, there is a 512MiB to 1.5GiB split between kernel
-	  and modules. When RANDOMIZE_BASE_MAX_OFFSET is above 512MiB, the
-	  modules area will shrink to compensate, up to the current maximum
-	  1GiB to 1GiB split. The default is 1GiB.
-
-	  If unsure, leave at the default value.
+	  If unsure, say N.
 
 # Relocation on x86 needs some additional build support
 config X86_NEED_RELOCS
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 7d86c5dd8e99..3ad71a0afa24 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -217,15 +217,13 @@ static bool mem_avoid_overlap(struct mem_vector *img)
 	return false;
 }
 
-static unsigned long slots[CONFIG_RANDOMIZE_BASE_MAX_OFFSET /
-			   CONFIG_PHYSICAL_ALIGN];
+static unsigned long slots[KERNEL_IMAGE_SIZE / CONFIG_PHYSICAL_ALIGN];
 static unsigned long slot_max;
 
 static void slots_append(unsigned long addr)
 {
 	/* Overflowing the slots list should be impossible. */
-	if (slot_max >= CONFIG_RANDOMIZE_BASE_MAX_OFFSET /
-			CONFIG_PHYSICAL_ALIGN)
+	if (slot_max >= KERNEL_IMAGE_SIZE / CONFIG_PHYSICAL_ALIGN)
 		return;
 
 	slots[slot_max++] = addr;
@@ -251,7 +249,7 @@ static void process_e820_entry(struct e820entry *entry,
 		return;
 
 	/* Ignore entries entirely above our maximum. */
-	if (entry->addr >= CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
+	if (entry->addr >= KERNEL_IMAGE_SIZE)
 		return;
 
 	/* Ignore entries entirely below our minimum. */
@@ -276,8 +274,8 @@ static void process_e820_entry(struct e820entry *entry,
 	region.size -= region.start - entry->addr;
 
 	/* Reduce maximum size to fit end of image within maximum limit. */
-	if (region.start + region.size > CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
-		region.size = CONFIG_RANDOMIZE_BASE_MAX_OFFSET - region.start;
+	if (region.start + region.size > KERNEL_IMAGE_SIZE)
+		region.size = KERNEL_IMAGE_SIZE - region.start;
 
 	/* Walk each aligned slot and check for avoided areas. */
 	for (img.start = region.start, img.size = image_size ;
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 4928cf0d5af0..d5c2f8b40faa 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -47,12 +47,10 @@
  * are fully set up. If kernel ASLR is configured, it can extend the
  * kernel page table mapping, reducing the size of the modules area.
  */
-#define KERNEL_IMAGE_SIZE_DEFAULT      (512 * 1024 * 1024)
-#if defined(CONFIG_RANDOMIZE_BASE) && \
-	CONFIG_RANDOMIZE_BASE_MAX_OFFSET > KERNEL_IMAGE_SIZE_DEFAULT
-#define KERNEL_IMAGE_SIZE   CONFIG_RANDOMIZE_BASE_MAX_OFFSET
+#if defined(CONFIG_RANDOMIZE_BASE)
+#define KERNEL_IMAGE_SIZE	(1024 * 1024 * 1024)
 #else
-#define KERNEL_IMAGE_SIZE      KERNEL_IMAGE_SIZE_DEFAULT
+#define KERNEL_IMAGE_SIZE	(512 * 1024 * 1024)
 #endif
 
 #endif /* _ASM_X86_PAGE_64_DEFS_H */
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index bd7a9b9e2e14..f2ee42d61894 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -804,9 +804,6 @@ void __init mem_init(void)
 	BUILD_BUG_ON(VMALLOC_START			>= VMALLOC_END);
 #undef high_memory
 #undef __FIXADDR_TOP
-#ifdef CONFIG_RANDOMIZE_BASE
-	BUILD_BUG_ON(CONFIG_RANDOMIZE_BASE_MAX_OFFSET > KERNEL_IMAGE_SIZE);
-#endif
 
 #ifdef CONFIG_HIGHMEM
 	BUG_ON(PKMAP_BASE + LAST_PKMAP*PAGE_SIZE	> FIXADDR_START);
-- 
2.6.3

[toc] | [next] | [standalone]

#1384459

FromBorislav Petkov <bp@suse.de>
Date2016-04-21 19:50 +0200
Message-ID<rqqTN-4ry-21@gated-at.bofh.it>
In reply to#1383736
On Wed, Apr 20, 2016 at 01:55:43PM -0700, Kees Cook wrote:
> From: Baoquan He <bhe@redhat.com>
> 
> Currently CONFIG_RANDOMIZE_BASE_MAX_OFFSET is used to limit the maximum
> offset for kernel randomization. This limit doesn't need to be a CONFIG
> since it is tied completely to KERNEL_IMAGE_SIZE, and will make no sense
> once physical and virtual offsets are randomized separately. This patch
> removes CONFIG_RANDOMIZE_BASE_MAX_OFFSET and consolidates the Kconfig
> help text.
> 
> Signed-off-by: Baoquan He <bhe@redhat.com>
> [kees: rewrote changelog, dropped KERNEL_IMAGE_SIZE_DEFAULT, rewrote help]
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  arch/x86/Kconfig                     | 72 ++++++++++++++----------------------
>  arch/x86/boot/compressed/kaslr.c     | 12 +++---
>  arch/x86/include/asm/page_64_types.h |  8 ++--
>  arch/x86/mm/init_32.c                |  3 --
>  4 files changed, 36 insertions(+), 59 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 2dc18605831f..5892d549596d 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1932,54 +1932,38 @@ config RELOCATABLE
>  	  (CONFIG_PHYSICAL_START) is used as the minimum location.
>  
>  config RANDOMIZE_BASE
> -	bool "Randomize the address of the kernel image"
> +	bool "Randomize the address of the kernel image (KASLR)"
>  	depends on RELOCATABLE
>  	default n
>  	---help---
> -	   Randomizes the physical and virtual address at which the
> -	   kernel image is decompressed, as a security feature that
> -	   deters exploit attempts relying on knowledge of the location
> -	   of kernel internals.
> +	  In support of Kernel Address Space Layout Randomization (KASLR),
> +	  this randomizes the physical address at which the kernel image
> +	  is decompressed and the virtual address where the kernel

Just say "loaded" here.

> +	  image is mapped, as a security feature that deters exploit
> +	  attempts relying on knowledge of the location of kernel
> +	  code internals.
> +
> +	  The kernel physical and virtual address can be randomized
> +	  from 16MB up to 1GB on 64-bit and 512MB on 32-bit. (Note that
> +	  using RANDOMIZE_BASE reduces the memory space available to
> +	  kernel modules from 1.5GB to 1GB.)
> +
> +	  Entropy is generated using the RDRAND instruction if it is
> +	  supported. If RDTSC is supported, its value is mixed into
> +	  the entropy pool as well. If neither RDRAND nor RDTSC are
> +	  supported, then entropy is read from the i8254 timer.
> +
> +	  Since the kernel is built using 2GB addressing,

Does that try to refer to the 1G kernel and 1G fixmap pagetable
mappings? I.e., level2_kernel_pgt and level2_fixmap_pgt in
arch/x86/kernel/head_64.S?

> and
> +	  PHYSICAL_ALIGN must be at a minimum of 2MB, only 10 bits of
> +	  entropy is theoretically possible. Currently, with the
> +	  default value for PHYSICAL_ALIGN and due to page table
> +	  layouts, 64-bit uses 9 bits of entropy and 32-bit uses 8 bits.
> +
> +	  If CONFIG_HIBERNATE is also enabled, KASLR is disabled at boot
> +	  time. To enable it, boot with "kaslr" on the kernel command
> +	  line (which will also disable hibernation).

...

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--

[toc] | [prev] | [next] | [standalone]

#1384488

FromKees Cook <keescook@chromium.org>
Date2016-04-21 20:20 +0200
Message-ID<rqrmO-52G-37@gated-at.bofh.it>
In reply to#1384459
On Thu, Apr 21, 2016 at 10:44 AM, Borislav Petkov <bp@suse.de> wrote:
> On Wed, Apr 20, 2016 at 01:55:43PM -0700, Kees Cook wrote:
>> From: Baoquan He <bhe@redhat.com>
>>
>> Currently CONFIG_RANDOMIZE_BASE_MAX_OFFSET is used to limit the maximum
>> offset for kernel randomization. This limit doesn't need to be a CONFIG
>> since it is tied completely to KERNEL_IMAGE_SIZE, and will make no sense
>> once physical and virtual offsets are randomized separately. This patch
>> removes CONFIG_RANDOMIZE_BASE_MAX_OFFSET and consolidates the Kconfig
>> help text.
>>
>> Signed-off-by: Baoquan He <bhe@redhat.com>
>> [kees: rewrote changelog, dropped KERNEL_IMAGE_SIZE_DEFAULT, rewrote help]
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>>  arch/x86/Kconfig                     | 72 ++++++++++++++----------------------
>>  arch/x86/boot/compressed/kaslr.c     | 12 +++---
>>  arch/x86/include/asm/page_64_types.h |  8 ++--
>>  arch/x86/mm/init_32.c                |  3 --
>>  4 files changed, 36 insertions(+), 59 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 2dc18605831f..5892d549596d 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1932,54 +1932,38 @@ config RELOCATABLE
>>         (CONFIG_PHYSICAL_START) is used as the minimum location.
>>
>>  config RANDOMIZE_BASE
>> -     bool "Randomize the address of the kernel image"
>> +     bool "Randomize the address of the kernel image (KASLR)"
>>       depends on RELOCATABLE
>>       default n
>>       ---help---
>> -        Randomizes the physical and virtual address at which the
>> -        kernel image is decompressed, as a security feature that
>> -        deters exploit attempts relying on knowledge of the location
>> -        of kernel internals.
>> +       In support of Kernel Address Space Layout Randomization (KASLR),
>> +       this randomizes the physical address at which the kernel image
>> +       is decompressed and the virtual address where the kernel
>
> Just say "loaded" here.

Okay, works for me. This will get some changes after the phys/virt is split.

>
>> +       image is mapped, as a security feature that deters exploit
>> +       attempts relying on knowledge of the location of kernel
>> +       code internals.
>> +
>> +       The kernel physical and virtual address can be randomized
>> +       from 16MB up to 1GB on 64-bit and 512MB on 32-bit. (Note that
>> +       using RANDOMIZE_BASE reduces the memory space available to
>> +       kernel modules from 1.5GB to 1GB.)
>> +
>> +       Entropy is generated using the RDRAND instruction if it is
>> +       supported. If RDTSC is supported, its value is mixed into
>> +       the entropy pool as well. If neither RDRAND nor RDTSC are
>> +       supported, then entropy is read from the i8254 timer.
>> +
>> +       Since the kernel is built using 2GB addressing,
>
> Does that try to refer to the 1G kernel and 1G fixmap pagetable
> mappings? I.e., level2_kernel_pgt and level2_fixmap_pgt in
> arch/x86/kernel/head_64.S?

The "2GB addressing" part is in reference to:

       -mcmodel=kernel
           Generate code for the kernel code model.  The kernel runs in the
           negative 2 GB of the address space.  This model has to be used for
           Linux kernel code.

>
>> and
>> +       PHYSICAL_ALIGN must be at a minimum of 2MB, only 10 bits of
>> +       entropy is theoretically possible. Currently, with the
>> +       default value for PHYSICAL_ALIGN and due to page table

This ("page table layouts") really means fixmap and (lack of) identity
mappings. I was trying to remove some level of jargon at Ingo's
request, so this area got a bit vague. I'm happy to rewrite this
however people think is best.

>> +       layouts, 64-bit uses 9 bits of entropy and 32-bit uses 8 bits.
>> +
>> +       If CONFIG_HIBERNATE is also enabled, KASLR is disabled at boot
>> +       time. To enable it, boot with "kaslr" on the kernel command
>> +       line (which will also disable hibernation).
>
> ...
>
> --
> Regards/Gruss,
>     Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
> --

Thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1384734

FromIngo Molnar <mingo@kernel.org>
Date2016-04-22 09:20 +0200
Message-ID<rqDxE-6zr-1@gated-at.bofh.it>
In reply to#1384488
* Kees Cook <keescook@chromium.org> wrote:

> >> +       Since the kernel is built using 2GB addressing,
> >
> > Does that try to refer to the 1G kernel and 1G fixmap pagetable
> > mappings? I.e., level2_kernel_pgt and level2_fixmap_pgt in
> > arch/x86/kernel/head_64.S?
> 
> The "2GB addressing" part is in reference to:
> 
>        -mcmodel=kernel
>            Generate code for the kernel code model.  The kernel runs in the
>            negative 2 GB of the address space.  This model has to be used for
>            Linux kernel code.

On x86-64 this is a special GCC compiler small memory model, it is called the 
'kernel code model', which is rather generic and no 'real name' ever stuck.

Due to RIP-relative addressing and the sign-extension of 48 bit virtual addresses, 
this allows nearly as compact kernel code and (static) kernel data definitions as 
a 32-bit kernel would allow.

The (positive) 0-4GB virtual memory range has similar advantages, but is of course 
frequently used by user-space code. Negative addresses are reserved for the kernel 
only.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1384833

FromBorislav Petkov <bp@suse.de>
Date2016-04-22 11:50 +0200
Message-ID<rqFSP-8hs-15@gated-at.bofh.it>
In reply to#1384734
On Fri, Apr 22, 2016 at 09:16:12AM +0200, Ingo Molnar wrote:
> 
> * Kees Cook <keescook@chromium.org> wrote:
> 
> > >> +       Since the kernel is built using 2GB addressing,
> > >
> > > Does that try to refer to the 1G kernel and 1G fixmap pagetable
> > > mappings? I.e., level2_kernel_pgt and level2_fixmap_pgt in
> > > arch/x86/kernel/head_64.S?
> > 
> > The "2GB addressing" part is in reference to:
> > 
> >        -mcmodel=kernel
> >            Generate code for the kernel code model.  The kernel runs in the
> >            negative 2 GB of the address space.  This model has to be used for
> >            Linux kernel code.
> 
> On x86-64 this is a special GCC compiler small memory model, it is called the 
> 'kernel code model', which is rather generic and no 'real name' ever stuck.
> 
> Due to RIP-relative addressing and the sign-extension of 48 bit virtual addresses, 
> this allows nearly as compact kernel code and (static) kernel data definitions as 
> a 32-bit kernel would allow.
> 
> The (positive) 0-4GB virtual memory range has similar advantages, but is of course 
> frequently used by user-space code. Negative addresses are reserved for the kernel 
> only.

So it wouldn't hurt to have a more detailed explanation like this one in
the text. And the 2G thing confused me maybe because it actually means
32-bit: 0x8000_0000 is 2G and is negative since the MSB is 1b. And I was
wondering: "but what about 64-bit...?"

Thanks.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--

[toc] | [prev] | [next] | [standalone]

#1384837 — [tip:x86/boot] x86/KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET

Fromtip-bot for Baoquan He <tipbot@zytor.com>
Date2016-04-22 11:50 +0200
Subject[tip:x86/boot] x86/KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET
Message-ID<rqFSP-8hs-25@gated-at.bofh.it>
In reply to#1383736
Commit-ID:  e8581e3d67788b6b29d055fa42c6cb5b258fee64
Gitweb:     http://git.kernel.org/tip/e8581e3d67788b6b29d055fa42c6cb5b258fee64
Author:     Baoquan He <bhe@redhat.com>
AuthorDate: Wed, 20 Apr 2016 13:55:43 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 22 Apr 2016 10:00:50 +0200

x86/KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET

Currently CONFIG_RANDOMIZE_BASE_MAX_OFFSET is used to limit the maximum
offset for kernel randomization. This limit doesn't need to be a CONFIG
since it is tied completely to KERNEL_IMAGE_SIZE, and will make no sense
once physical and virtual offsets are randomized separately. This patch
removes CONFIG_RANDOMIZE_BASE_MAX_OFFSET and consolidates the Kconfig
help text.

[kees: rewrote changelog, dropped KERNEL_IMAGE_SIZE_DEFAULT, rewrote help]
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: H.J. Lu <hjl.tools@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1461185746-8017-3-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/Kconfig                     | 72 ++++++++++++++----------------------
 arch/x86/boot/compressed/kaslr.c     | 12 +++---
 arch/x86/include/asm/page_64_types.h |  8 ++--
 arch/x86/mm/init_32.c                |  3 --
 4 files changed, 36 insertions(+), 59 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2dc18605..5892d54 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1932,54 +1932,38 @@ config RELOCATABLE
 	  (CONFIG_PHYSICAL_START) is used as the minimum location.
 
 config RANDOMIZE_BASE
-	bool "Randomize the address of the kernel image"
+	bool "Randomize the address of the kernel image (KASLR)"
 	depends on RELOCATABLE
 	default n
 	---help---
-	   Randomizes the physical and virtual address at which the
-	   kernel image is decompressed, as a security feature that
-	   deters exploit attempts relying on knowledge of the location
-	   of kernel internals.
+	  In support of Kernel Address Space Layout Randomization (KASLR),
+	  this randomizes the physical address at which the kernel image
+	  is decompressed and the virtual address where the kernel
+	  image is mapped, as a security feature that deters exploit
+	  attempts relying on knowledge of the location of kernel
+	  code internals.
+
+	  The kernel physical and virtual address can be randomized
+	  from 16MB up to 1GB on 64-bit and 512MB on 32-bit. (Note that
+	  using RANDOMIZE_BASE reduces the memory space available to
+	  kernel modules from 1.5GB to 1GB.)
+
+	  Entropy is generated using the RDRAND instruction if it is
+	  supported. If RDTSC is supported, its value is mixed into
+	  the entropy pool as well. If neither RDRAND nor RDTSC are
+	  supported, then entropy is read from the i8254 timer.
+
+	  Since the kernel is built using 2GB addressing, and
+	  PHYSICAL_ALIGN must be at a minimum of 2MB, only 10 bits of
+	  entropy is theoretically possible. Currently, with the
+	  default value for PHYSICAL_ALIGN and due to page table
+	  layouts, 64-bit uses 9 bits of entropy and 32-bit uses 8 bits.
+
+	  If CONFIG_HIBERNATE is also enabled, KASLR is disabled at boot
+	  time. To enable it, boot with "kaslr" on the kernel command
+	  line (which will also disable hibernation).
 
-	   Entropy is generated using the RDRAND instruction if it is
-	   supported. If RDTSC is supported, it is used as well. If
-	   neither RDRAND nor RDTSC are supported, then randomness is
-	   read from the i8254 timer.
-
-	   The kernel will be offset by up to RANDOMIZE_BASE_MAX_OFFSET,
-	   and aligned according to PHYSICAL_ALIGN. Since the kernel is
-	   built using 2GiB addressing, and PHYSICAL_ALGIN must be at a
-	   minimum of 2MiB, only 10 bits of entropy is theoretically
-	   possible. At best, due to page table layouts, 64-bit can use
-	   9 bits of entropy and 32-bit uses 8 bits.
-
-	   If unsure, say N.
-
-config RANDOMIZE_BASE_MAX_OFFSET
-	hex "Maximum kASLR offset allowed" if EXPERT
-	depends on RANDOMIZE_BASE
-	range 0x0 0x20000000 if X86_32
-	default "0x20000000" if X86_32
-	range 0x0 0x40000000 if X86_64
-	default "0x40000000" if X86_64
-	---help---
-	  The lesser of RANDOMIZE_BASE_MAX_OFFSET and available physical
-	  memory is used to determine the maximal offset in bytes that will
-	  be applied to the kernel when kernel Address Space Layout
-	  Randomization (kASLR) is active. This must be a multiple of
-	  PHYSICAL_ALIGN.
-
-	  On 32-bit this is limited to 512MiB by page table layouts. The
-	  default is 512MiB.
-
-	  On 64-bit this is limited by how the kernel fixmap page table is
-	  positioned, so this cannot be larger than 1GiB currently. Without
-	  RANDOMIZE_BASE, there is a 512MiB to 1.5GiB split between kernel
-	  and modules. When RANDOMIZE_BASE_MAX_OFFSET is above 512MiB, the
-	  modules area will shrink to compensate, up to the current maximum
-	  1GiB to 1GiB split. The default is 1GiB.
-
-	  If unsure, leave at the default value.
+	  If unsure, say N.
 
 # Relocation on x86 needs some additional build support
 config X86_NEED_RELOCS
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 7d86c5d..3ad71a0 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -217,15 +217,13 @@ static bool mem_avoid_overlap(struct mem_vector *img)
 	return false;
 }
 
-static unsigned long slots[CONFIG_RANDOMIZE_BASE_MAX_OFFSET /
-			   CONFIG_PHYSICAL_ALIGN];
+static unsigned long slots[KERNEL_IMAGE_SIZE / CONFIG_PHYSICAL_ALIGN];
 static unsigned long slot_max;
 
 static void slots_append(unsigned long addr)
 {
 	/* Overflowing the slots list should be impossible. */
-	if (slot_max >= CONFIG_RANDOMIZE_BASE_MAX_OFFSET /
-			CONFIG_PHYSICAL_ALIGN)
+	if (slot_max >= KERNEL_IMAGE_SIZE / CONFIG_PHYSICAL_ALIGN)
 		return;
 
 	slots[slot_max++] = addr;
@@ -251,7 +249,7 @@ static void process_e820_entry(struct e820entry *entry,
 		return;
 
 	/* Ignore entries entirely above our maximum. */
-	if (entry->addr >= CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
+	if (entry->addr >= KERNEL_IMAGE_SIZE)
 		return;
 
 	/* Ignore entries entirely below our minimum. */
@@ -276,8 +274,8 @@ static void process_e820_entry(struct e820entry *entry,
 	region.size -= region.start - entry->addr;
 
 	/* Reduce maximum size to fit end of image within maximum limit. */
-	if (region.start + region.size > CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
-		region.size = CONFIG_RANDOMIZE_BASE_MAX_OFFSET - region.start;
+	if (region.start + region.size > KERNEL_IMAGE_SIZE)
+		region.size = KERNEL_IMAGE_SIZE - region.start;
 
 	/* Walk each aligned slot and check for avoided areas. */
 	for (img.start = region.start, img.size = image_size ;
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 4928cf0..d5c2f8b 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -47,12 +47,10 @@
  * are fully set up. If kernel ASLR is configured, it can extend the
  * kernel page table mapping, reducing the size of the modules area.
  */
-#define KERNEL_IMAGE_SIZE_DEFAULT      (512 * 1024 * 1024)
-#if defined(CONFIG_RANDOMIZE_BASE) && \
-	CONFIG_RANDOMIZE_BASE_MAX_OFFSET > KERNEL_IMAGE_SIZE_DEFAULT
-#define KERNEL_IMAGE_SIZE   CONFIG_RANDOMIZE_BASE_MAX_OFFSET
+#if defined(CONFIG_RANDOMIZE_BASE)
+#define KERNEL_IMAGE_SIZE	(1024 * 1024 * 1024)
 #else
-#define KERNEL_IMAGE_SIZE      KERNEL_IMAGE_SIZE_DEFAULT
+#define KERNEL_IMAGE_SIZE	(512 * 1024 * 1024)
 #endif
 
 #endif /* _ASM_X86_PAGE_64_DEFS_H */
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index bd7a9b9..f2ee42d 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -804,9 +804,6 @@ void __init mem_init(void)
 	BUILD_BUG_ON(VMALLOC_START			>= VMALLOC_END);
 #undef high_memory
 #undef __FIXADDR_TOP
-#ifdef CONFIG_RANDOMIZE_BASE
-	BUILD_BUG_ON(CONFIG_RANDOMIZE_BASE_MAX_OFFSET > KERNEL_IMAGE_SIZE);
-#endif
 
 #ifdef CONFIG_HIGHMEM
 	BUG_ON(PKMAP_BASE + LAST_PKMAP*PAGE_SIZE	> FIXADDR_START);

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web