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

Groups > linux.kernel > #1428295 > unrolled thread

[PATCH v7 0/9] x86/mm: memory area address KASLR

Back to article view | Back to linux.kernel

Contents

  [PATCH v7 0/9] x86/mm: memory area address KASLR Kees Cook <keescook@chromium.org> - 2016-06-22 02:50 +0200
    [PATCH v7 4/9] x86/mm: Separate variable for trampoline PGD (x86_64) Kees Cook <keescook@chromium.org> - 2016-06-22 02:50 +0200
    Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address  KASLR Jason Cooper <jason@lakedaemon.net> - 2016-06-22 14:50 +0200
      Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR Thomas Garnier <thgarnie@google.com> - 2016-06-22 18:00 +0200
        Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR Kees Cook <keescook@chromium.org> - 2016-06-22 19:10 +0200

#1428295 — [PATCH v7 0/9] x86/mm: memory area address KASLR

This is v7 of Thomas Garnier's KASLR for memory areas (physical memory
mapping, vmalloc, vmemmap). It expects to be applied on top of the
x86/boot tip.

The current implementation of KASLR randomizes only the base address of
the kernel and its modules. Research was published showing that static
memory addresses can be found and used in exploits, effectively ignoring
base address KASLR:

   The physical memory mapping holds most allocations from boot and
   heap allocators. Knowning the base address and physical memory
   size, an attacker can deduce the PDE virtual address for the vDSO
   memory page.  This attack was demonstrated at CanSecWest 2016, in
   the "Getting Physical: Extreme Abuse of Intel Based Paged Systems"
   https://goo.gl/ANpWdV (see second part of the presentation). The
   exploits used against Linux worked successfuly against 4.6+ but fail
   with KASLR memory enabled (https://goo.gl/iTtXMJ). Similar research
   was done at Google leading to this patch proposal. Variants exists
   to overwrite /proc or /sys objects ACLs leading to elevation of
   privileges.  These variants were tested against 4.6+.

This set of patches randomizes the base address and padding of three
major memory sections (physical memory mapping, vmalloc, and vmemmap).
It mitigates exploits relying on predictable kernel addresses in these
areas. This feature can be enabled with the CONFIG_RANDOMIZE_MEMORY
option. (This CONFIG, along with CONFIG_RANDOMIZE may be renamed in
the future, but stands for now as other architectures continue to
implement KASLR.)

Padding for the memory hotplug support is managed by
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING. The default value is 10
terabytes.

The patches were tested on qemu & physical machines. Xen compatibility was
also verified. Multiple reboots were used to verify entropy for each
memory section.

Notable problems that needed solving:
 - The three target memory sections need to not be at the same place
   across reboots.
 - The physical memory mapping can use a virtual address not aligned on
   the PGD page table.
 - Reasonable entropy is needed early at boot before get_random_bytes()
   is available.
 - Memory hotplug needs KASLR padding.

Patches:
 - 1: refactor KASLR functions (moves them from boot/compressed/ into lib/)
 - 2: clarifies the variables used for physical mapping.
 - 3: PUD virtual address support for physical mapping.
 - 4: split out the trampoline PGD
 - 5: KASLR memory infrastructure code
 - 6: randomize base of physical mapping region
 - 7: randomize base of vmalloc region
 - 8: randomize base of vmemmap region
 - 9: provide memory hotplug padding support

There is no measurable performance impact:

 - Kernbench shows almost no difference (-+ less than 1%).
 - Hackbench shows 0% difference on average (hackbench 90 repeated 10 times).

[toc] | [next] | [standalone]

#1428296 — [PATCH v7 4/9] x86/mm: Separate variable for trampoline PGD (x86_64)

From: Thomas Garnier <thgarnie@google.com>

Use a separate global variable to define the trampoline PGD used to
start other processors. This change will allow KALSR memory
randomization to change the trampoline PGD to be correctly aligned with
physical memory.

Signed-off-by: Thomas Garnier <thgarnie@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/include/asm/pgtable.h | 12 ++++++++++++
 arch/x86/mm/init.c             |  3 +++
 arch/x86/realmode/init.c       |  5 ++++-
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 1a27396b6ea0..d455bef39e9c 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -729,6 +729,18 @@ extern int direct_gbpages;
 void init_mem_mapping(void);
 void early_alloc_pgt_buf(void);
 
+#ifdef CONFIG_X86_64
+/* Realmode trampoline initialization. */
+extern pgd_t trampoline_pgd_entry;
+static inline void __meminit init_trampoline(void)
+{
+	/* Default trampoline pgd value */
+	trampoline_pgd_entry = init_level4_pgt[pgd_index(__PAGE_OFFSET)];
+}
+#else
+static inline void init_trampoline(void) { }
+#endif
+
 /* local pte updates need not use xchg for locking */
 static inline pte_t native_local_ptep_get_and_clear(pte_t *ptep)
 {
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 372aad2b3291..4252acdfcbbd 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -590,6 +590,9 @@ void __init init_mem_mapping(void)
 	/* the ISA range is always mapped regardless of memory holes */
 	init_memory_mapping(0, ISA_END_ADDRESS);
 
+	/* Init the trampoline, possibly with KASLR memory offset */
+	init_trampoline();
+
 	/*
 	 * If the allocation is in bottom-up direction, we setup direct mapping
 	 * in bottom-up, otherwise we setup direct mapping in top-down.
diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
index 0b7a63d98440..705e3fffb4a1 100644
--- a/arch/x86/realmode/init.c
+++ b/arch/x86/realmode/init.c
@@ -8,6 +8,9 @@
 struct real_mode_header *real_mode_header;
 u32 *trampoline_cr4_features;
 
+/* Hold the pgd entry used on booting additional CPUs */
+pgd_t trampoline_pgd_entry;
+
 void __init reserve_real_mode(void)
 {
 	phys_addr_t mem;
@@ -84,7 +87,7 @@ void __init setup_real_mode(void)
 	*trampoline_cr4_features = __read_cr4();
 
 	trampoline_pgd = (u64 *) __va(real_mode_header->trampoline_pgd);
-	trampoline_pgd[0] = init_level4_pgt[pgd_index(__PAGE_OFFSET)].pgd;
+	trampoline_pgd[0] = trampoline_pgd_entry.pgd;
 	trampoline_pgd[511] = init_level4_pgt[511].pgd;
 #endif
 }
-- 
2.7.4

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

#1428766 — Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

Hey Kees,

On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
> Notable problems that needed solving:
...
>  - Reasonable entropy is needed early at boot before get_random_bytes()
>    is available.

This series is targetting x86, which typically has RDRAND/RDSEED
instructions.  Are you referring to other arches?  Older x86?  Also,
isn't this the same requirement for base address KASLR?

Don't get me wrong, I want more diverse entropy sources available
earlier in the boot process as well. :-)  I'm just wondering what's
different about this series vs base address KASLR wrt early entropy
sources.

thx,

Jason.

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

#1428924 — Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> Hey Kees,
>
> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>> Notable problems that needed solving:
> ...
>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>>    is available.
>
> This series is targetting x86, which typically has RDRAND/RDSEED
> instructions.  Are you referring to other arches?  Older x86?  Also,
> isn't this the same requirement for base address KASLR?
>
> Don't get me wrong, I want more diverse entropy sources available
> earlier in the boot process as well. :-)  I'm just wondering what's
> different about this series vs base address KASLR wrt early entropy
> sources.
>

I think Kees was referring to the refactor I did to get the similar
entropy generation than KASLR module randomization. Our approach was
to provide best entropy possible even if you have an older processor
or under virtualization without support for these instructions.
Unfortunately common on companies with a large number of older
machines.

> thx,
>
> Jason.

Thanks,
Thomas

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

#1428990 — Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier <thgarnie@google.com> wrote:
> On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper <jason@lakedaemon.net> wrote:
>> Hey Kees,
>>
>> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>>> Notable problems that needed solving:
>> ...
>>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>>>    is available.
>>
>> This series is targetting x86, which typically has RDRAND/RDSEED
>> instructions.  Are you referring to other arches?  Older x86?  Also,
>> isn't this the same requirement for base address KASLR?
>>
>> Don't get me wrong, I want more diverse entropy sources available
>> earlier in the boot process as well. :-)  I'm just wondering what's
>> different about this series vs base address KASLR wrt early entropy
>> sources.
>>
>
> I think Kees was referring to the refactor I did to get the similar
> entropy generation than KASLR module randomization. Our approach was
> to provide best entropy possible even if you have an older processor
> or under virtualization without support for these instructions.
> Unfortunately common on companies with a large number of older
> machines.

Right, the memory offset KASLR uses the same routines as the kernel
base KASLR. The issue is with older x86 systems, which continue to be
very common.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web