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
      [tip:x86/boot] x86/mm: Separate variable for trampoline PGD tip-bot for Thomas Garnier <tipbot@zytor.com> - 2016-07-08 23:40 +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
          Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address  KASLR Jason Cooper <jason@lakedaemon.net> - 2016-06-23 21:40 +0200
            Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR Sandy Harris <sandyinchina@gmail.com> - 2016-06-23 21:50 +0200
              Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR Kees Cook <keescook@chromium.org> - 2016-06-23 22:00 +0200
                Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address  KASLR Jason Cooper <jason@lakedaemon.net> - 2016-06-23 22:20 +0200
              Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address  KASLR Jason Cooper <jason@lakedaemon.net> - 2016-06-23 22:20 +0200
            Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR Kees Cook <keescook@chromium.org> - 2016-06-23 22:00 +0200
              Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-06-23 22:10 +0200
                Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address  KASLR Jason Cooper <jason@lakedaemon.net> - 2016-06-24 03:20 +0200
                  Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-06-24 13:00 +0200
                    devicetree random-seed properties, was: "Re: [PATCH v7 0/9] x86/mm:  memory area address KASLR" Jason Cooper <jason@lakedaemon.net> - 2016-06-24 18:10 +0200
                      Re: devicetree random-seed properties, was: "Re: [PATCH v7 0/9]  x86/mm: memory area address KASLR" Kees Cook <keescook@chromium.org> - 2016-06-24 21:10 +0200
                        Re: devicetree random-seed properties, was: "Re: [PATCH v7 0/9]  x86/mm: memory area address KASLR" Andy Lutomirski <luto@amacapital.net> - 2016-06-24 22:50 +0200
                          Re: devicetree random-seed properties, was: "Re: [PATCH v7 0/9]  x86/mm: memory area address KASLR" Jason Cooper <jason@lakedaemon.net> - 2016-06-30 23:50 +0200
                        Re: devicetree random-seed properties, was: "Re: [PATCH v7 0/9]  x86/mm: memory area address KASLR" Jason Cooper <jason@lakedaemon.net> - 2016-06-30 23:50 +0200
    Re: [PATCH v7 0/9] x86/mm: memory area address KASLR Kees Cook <keescook@chromium.org> - 2016-07-08 00:30 +0200

Page 1 of 2  [1] 2  Next page →

#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]

#1439807 — [tip:x86/boot] x86/mm: Separate variable for trampoline PGD

Commit-ID:  b234e8a09003af108d3573f0369e25c080676b14
Gitweb:     http://git.kernel.org/tip/b234e8a09003af108d3573f0369e25c080676b14
Author:     Thomas Garnier <thgarnie@google.com>
AuthorDate: Tue, 21 Jun 2016 17:47:01 -0700
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 8 Jul 2016 17:33:46 +0200

x86/mm: Separate variable for trampoline PGD

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>
Cc: Alexander Kuleshov <kuleshovmail@gmail.com>
Cc: Alexander Popov <alpopov@ptsecurity.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Lv Zheng <lv.zheng@intel.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: kernel-hardening@lists.openwall.com
Cc: linux-doc@vger.kernel.org
Link: http://lkml.kernel.org/r/1466556426-32664-5-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.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 1a27396..d455bef 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 372aad2..4252acd 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 0b7a63d..705e3ff 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
 }

[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] | [next] | [standalone]

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

Hey Kees, Thomas,

On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
> 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.

We have the same issue in embedded. :-(  Compounded by the fact that
there is no rand instruction (at least not on ARM).  So, even if there's
a HW-RNG, you can't access it until the driver is loaded.

This is compounded by the fact that most systems deployed today have
bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
without dtb support at all.

My current thinking is to add a devicetree property
"userspace,random-seed" <address, len>.  This way, existing, deployed
boards can append a dtb to a modern kernel with the property set.
The factory bootloader then only needs to amend its boot scripts to read
random-seed from the fs to the given address.

Modern systems that receive a seed from the bootloader via the
random-seed property (typically from the hw-rng) can mix both sources
for increased resilience.

Unfortunately, I'm not very familiar with the internals of x86
bootstrapping.  Could GRUB be scripted to do a similar task?  How would
the address and size of the seed be passed to the kernel?  command line?

thx,

Jason.

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

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

Jason Cooper <jason@lakedaemon.net> wrote:

> Modern systems that receive a seed from the bootloader via the
> random-seed property (typically from the hw-rng) can mix both sources
> for increased resilience.
>
> Unfortunately, I'm not very familiar with the internals of x86
> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> the address and size of the seed be passed to the kernel?  command line?

One suggestion is at:
http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

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

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

On Thu, Jun 23, 2016 at 12:45 PM, Sandy Harris <sandyinchina@gmail.com> wrote:
> Jason Cooper <jason@lakedaemon.net> wrote:
>
>> Modern systems that receive a seed from the bootloader via the
>> random-seed property (typically from the hw-rng) can mix both sources
>> for increased resilience.
>>
>> Unfortunately, I'm not very familiar with the internals of x86
>> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
>> the address and size of the seed be passed to the kernel?  command line?
>
> One suggestion is at:
> http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

Interesting! This might pose a problem for signed images, though.
(Actually, for signed arm kernels is the DT signed too? If so, it
would be a similar problem.)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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

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

On Thu, Jun 23, 2016 at 12:59:07PM -0700, Kees Cook wrote:
> On Thu, Jun 23, 2016 at 12:45 PM, Sandy Harris <sandyinchina@gmail.com> wrote:
> > Jason Cooper <jason@lakedaemon.net> wrote:
> >
> >> Modern systems that receive a seed from the bootloader via the
> >> random-seed property (typically from the hw-rng) can mix both sources
> >> for increased resilience.
> >>
> >> Unfortunately, I'm not very familiar with the internals of x86
> >> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> >> the address and size of the seed be passed to the kernel?  command line?
> >
> > One suggestion is at:
> > http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image
> 
> Interesting! This might pose a problem for signed images, though.
> (Actually, for signed arm kernels is the DT signed too? If so, it
> would be a similar problem.)

That's the reason for userspace,random-seed = <address, size>.  Once
set, the dtb never has to change.  The bootloader loads the file to the
same address at each boot.  Userspace is responsible, as it is already,
for updating the random-seed file while up.

thx,

Jason.

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

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

Hey Sandy,

On Thu, Jun 23, 2016 at 03:45:54PM -0400, Sandy Harris wrote:
> Jason Cooper <jason@lakedaemon.net> wrote:
> 
> > Modern systems that receive a seed from the bootloader via the
> > random-seed property (typically from the hw-rng) can mix both sources
> > for increased resilience.
> >
> > Unfortunately, I'm not very familiar with the internals of x86
> > bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> > the address and size of the seed be passed to the kernel?  command line?
> 
> One suggestion is at:
> http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

Yes, this is very similar to the latent_entropy series that I think Kees
just merged.  Well, at a high level, it is.  'store a seed in the
kernel, use it at reboot'.

These approaches are good in that they provide yet another source of
entropy to the kernel.  However, both suffer from the kernel binary
being very static in time and across distro installs.  Particularly with
embedded systems.  It almost becomes a long term secret.  Which, the
longer it lives, the less chance there is of it being secret.

I'm not really comfortable with what John suggests, here:

"""
Next step: It should be straightforward to write a tool that efficiently
updates the stored seed within the boot image. Updating MUST occur
during provisioning, before the device gets booted for the first time
... and also from time to time thereafter. Updating the boot image isn’t
be quite as simple as dd of=/var/lib/urandom/random-seed but neither is
it rocket surgery. The cost is utterly negligible compared to the cost
of a security breach, which is the relevant comparison.
"""

Editing the installed kernel binary to add the seed is exposing the
system to unnecessary risk of bricking the system (e.g. powerfail
 halfway through) [0].  Yes, this can be mitigated by following a similar
process to kernel updates, but why?  The bootloader already knows how to
read a file into RAM.  We just need to put it in the right place and
tell it to do so.  And userspace already writes a new random-seed during
system init and clean shutdown.

We just need to connect the dots so deployed systems can use the seed
earlier without having to hack the kernel or update the bootloader.
Which, while possible, a lot of folks are skittish to do.

thx,

Jason.

[0] I imagine it also borks code-signing...

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

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

On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> Hey Kees, Thomas,
>
> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>> 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.
>
> We have the same issue in embedded. :-(  Compounded by the fact that
> there is no rand instruction (at least not on ARM).  So, even if there's
> a HW-RNG, you can't access it until the driver is loaded.
>
> This is compounded by the fact that most systems deployed today have
> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
> without dtb support at all.
>
> My current thinking is to add a devicetree property
> "userspace,random-seed" <address, len>.  This way, existing, deployed
> boards can append a dtb to a modern kernel with the property set.
> The factory bootloader then only needs to amend its boot scripts to read
> random-seed from the fs to the given address.

The arm64 KASLR implementation has defined a way for boot loaders to
pass in an seed similar to this. It might be nice to have a fall-back
to a DT entry, though, then the bootloaders don't need to changed.

Ard might have some thoughts on why DT wasn't used for KASLR (I assume
the early parsing overhead, but I don't remember the discussion any
more).

> Modern systems that receive a seed from the bootloader via the
> random-seed property (typically from the hw-rng) can mix both sources
> for increased resilience.

Yeah, that could work.

> Unfortunately, I'm not very familiar with the internals of x86
> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> the address and size of the seed be passed to the kernel?  command line?

Command line could work (though it would need scrubbing to avoid it
leaking into /proc/cmdine), but there's also the "zero-page" used by
bootloaders to pass details to the kernel (see
Documentation/x86/boot.txt). Right now, x86 has sufficient entropy
(though rdrand is best).

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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

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

On 23 June 2016 at 21:58, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper <jason@lakedaemon.net> wrote:
>> Hey Kees, Thomas,
>>
>> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>>> 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.
>>
>> We have the same issue in embedded. :-(  Compounded by the fact that
>> there is no rand instruction (at least not on ARM).  So, even if there's
>> a HW-RNG, you can't access it until the driver is loaded.
>>
>> This is compounded by the fact that most systems deployed today have
>> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
>> without dtb support at all.
>>
>> My current thinking is to add a devicetree property
>> "userspace,random-seed" <address, len>.  This way, existing, deployed
>> boards can append a dtb to a modern kernel with the property set.
>> The factory bootloader then only needs to amend its boot scripts to read
>> random-seed from the fs to the given address.
>
> The arm64 KASLR implementation has defined a way for boot loaders to
> pass in an seed similar to this. It might be nice to have a fall-back
> to a DT entry, though, then the bootloaders don't need to changed.
>
> Ard might have some thoughts on why DT wasn't used for KASLR (I assume
> the early parsing overhead, but I don't remember the discussion any
> more).
>

On arm64, only DT is used for KASLR (even when booting via ACPI). My
first draft used register x1, but this turned out to be too much of a
hassle, since parsing the DT is also necessary to discover whether
there is a 'nokaslr' argument on the kernel command line. So the
current implementation only supports a single method, which is the
/chosen/kaslr-seed uint64 property.

>> Modern systems that receive a seed from the bootloader via the
>> random-seed property (typically from the hw-rng) can mix both sources
>> for increased resilience.
>
> Yeah, that could work.
>
>> Unfortunately, I'm not very familiar with the internals of x86
>> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
>> the address and size of the seed be passed to the kernel?  command line?
>
> Command line could work (though it would need scrubbing to avoid it
> leaking into /proc/cmdine), but there's also the "zero-page" used by
> bootloaders to pass details to the kernel (see
> Documentation/x86/boot.txt). Right now, x86 has sufficient entropy
> (though rdrand is best).
>
> -Kees
>
> --
> Kees Cook
> Chrome OS & Brillo Security

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

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

Hi Ard,

On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
> On 23 June 2016 at 21:58, Kees Cook <keescook@chromium.org> wrote:
> > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
> >>> 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.
> >>
> >> We have the same issue in embedded. :-(  Compounded by the fact that
> >> there is no rand instruction (at least not on ARM).  So, even if there's
> >> a HW-RNG, you can't access it until the driver is loaded.
> >>
> >> This is compounded by the fact that most systems deployed today have
> >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
> >> without dtb support at all.
> >>
> >> My current thinking is to add a devicetree property
> >> "userspace,random-seed" <address, len>.  This way, existing, deployed
> >> boards can append a dtb to a modern kernel with the property set.
> >> The factory bootloader then only needs to amend its boot scripts to read
> >> random-seed from the fs to the given address.
> >
> > The arm64 KASLR implementation has defined a way for boot loaders to
> > pass in an seed similar to this. It might be nice to have a fall-back
> > to a DT entry, though, then the bootloaders don't need to changed.
> >
> > Ard might have some thoughts on why DT wasn't used for KASLR (I assume
> > the early parsing overhead, but I don't remember the discussion any
> > more).
> >
> 
> On arm64, only DT is used for KASLR (even when booting via ACPI). My
> first draft used register x1, but this turned out to be too much of a
> hassle, since parsing the DT is also necessary to discover whether
> there is a 'nokaslr' argument on the kernel command line. So the
> current implementation only supports a single method, which is the
> /chosen/kaslr-seed uint64 property.

Ok, just to clarify (after a short offline chat), my goal is to set a
userspace,random-seed <addr, len> property in the device tree once.
The bootloader scripts would also only need to be altered once.

Then, at each boot, the bootloader reads the entirety of
/var/lib/misc/random-seed (512 bytes) into the configured address.
random-seed could be in /boot, or on a flash partition.

The decompressor would consume a small portion of that seed for kaslr
and such.  After that, the rest would be consumed by random.c to
initialize the entropy pools.

thx,

Jason.

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

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

On 24 June 2016 at 03:11, Jason Cooper <jason@lakedaemon.net> wrote:
> Hi Ard,
>
> On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
>> On 23 June 2016 at 21:58, Kees Cook <keescook@chromium.org> wrote:
>> > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper <jason@lakedaemon.net> wrote:
>> >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>> >>> 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.
>> >>
>> >> We have the same issue in embedded. :-(  Compounded by the fact that
>> >> there is no rand instruction (at least not on ARM).  So, even if there's
>> >> a HW-RNG, you can't access it until the driver is loaded.
>> >>
>> >> This is compounded by the fact that most systems deployed today have
>> >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
>> >> without dtb support at all.
>> >>
>> >> My current thinking is to add a devicetree property
>> >> "userspace,random-seed" <address, len>.  This way, existing, deployed
>> >> boards can append a dtb to a modern kernel with the property set.
>> >> The factory bootloader then only needs to amend its boot scripts to read
>> >> random-seed from the fs to the given address.
>> >
>> > The arm64 KASLR implementation has defined a way for boot loaders to
>> > pass in an seed similar to this. It might be nice to have a fall-back
>> > to a DT entry, though, then the bootloaders don't need to changed.
>> >
>> > Ard might have some thoughts on why DT wasn't used for KASLR (I assume
>> > the early parsing overhead, but I don't remember the discussion any
>> > more).
>> >
>>
>> On arm64, only DT is used for KASLR (even when booting via ACPI). My
>> first draft used register x1, but this turned out to be too much of a
>> hassle, since parsing the DT is also necessary to discover whether
>> there is a 'nokaslr' argument on the kernel command line. So the
>> current implementation only supports a single method, which is the
>> /chosen/kaslr-seed uint64 property.
>
> Ok, just to clarify (after a short offline chat), my goal is to set a
> userspace,random-seed <addr, len> property in the device tree once.
> The bootloader scripts would also only need to be altered once.
>
> Then, at each boot, the bootloader reads the entirety of
> /var/lib/misc/random-seed (512 bytes) into the configured address.
> random-seed could be in /boot, or on a flash partition.
>
> The decompressor would consume a small portion of that seed for kaslr
> and such.  After that, the rest would be consumed by random.c to
> initialize the entropy pools.
>

I see. This indeed has little to do with the arm64 KASLR case, other
than that they both use a DT property.

In the arm64 KASLR case, I deliberately chose to leave it up to the
bootloader/firmware to roll the dice, for the same reason you pointed
out, i.e., that there is no architected way on ARM to obtain random
bits. So in that sense, what you are doing is complimentary to my
work, and a KASLR  aware arm64 bootloader would copy some of its
random bits taken from /var/lib/misc/random-seed into the
/chosen/kaslr-seed DT property. Note that, at the moment, this DT
property is only an internal contract between the kernel's UEFI stub
and the kernel proper, so we could still easily change that if
necessary.

Alternatively, if we go with your solution, the KASLR code should read
from the address in userspace,random-seed rather than the
/chosen/kaslr-seed property itself. (or use the former as a fallback
if the latter was not found)

-- 
Ard.

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

#1430791 — devicetree random-seed properties, was: "Re: [PATCH v7 0/9] x86/mm: memory area address KASLR"

Thomas,

Sorry for wandering off the topic of your series.  The big take away for
me is that you and Kees are concerned about x86 systems pre-RDRAND.
Just as I'm concerned about deployed embedded systems without bootloader
support for hw-rngs and so forth.

Whatever final form the approach takes for ARM/dt, I'll make sure we can
extend it to legacy x86 systems.


Ard,

On Fri, Jun 24, 2016 at 12:54:01PM +0200, Ard Biesheuvel wrote:
> On 24 June 2016 at 03:11, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
...
> >> On arm64, only DT is used for KASLR (even when booting via ACPI). My
> >> first draft used register x1, but this turned out to be too much of a
> >> hassle, since parsing the DT is also necessary to discover whether
> >> there is a 'nokaslr' argument on the kernel command line. So the
> >> current implementation only supports a single method, which is the
> >> /chosen/kaslr-seed uint64 property.
> >
> > Ok, just to clarify (after a short offline chat), my goal is to set a
> > userspace,random-seed <addr, len> property in the device tree once.
> > The bootloader scripts would also only need to be altered once.
> >
> > Then, at each boot, the bootloader reads the entirety of
> > /var/lib/misc/random-seed (512 bytes) into the configured address.
> > random-seed could be in /boot, or on a flash partition.
> >
> > The decompressor would consume a small portion of that seed for kaslr
> > and such.  After that, the rest would be consumed by random.c to
> > initialize the entropy pools.
> >
> 
> I see. This indeed has little to do with the arm64 KASLR case, other
> than that they both use a DT property.
> 
> In the arm64 KASLR case, I deliberately chose to leave it up to the
> bootloader/firmware to roll the dice, for the same reason you pointed
> out, i.e., that there is no architected way on ARM to obtain random
> bits. So in that sense, what you are doing is complimentary to my
> work, and a KASLR  aware arm64 bootloader would copy some of its
> random bits taken from /var/lib/misc/random-seed into the
> /chosen/kaslr-seed DT property.

Here I disagree.  We have two distinct entropy sources; the hw-rng
currently feeding kaslr via the /chosen/kaslr-seed property, and the
seasoned userspace seed I propose handed in via an extra property.

Having the bootloader conflate those two sources as if they are equal
seems to muddy the waters.  I prefer to have bootloaders tell me where
they got the data rather than to hope the bootloader sourced and mixed
it well.

> Note that, at the moment, this DT property is only an internal
> contract between the kernel's UEFI stub and the kernel proper, so we
> could still easily change that if necessary.

Ideally, I'd prefer to be deliberate with the DT properties, e.g.

random-seed,hwrng     <--- bootloader reads from hw-rng
random-seed,userspace <--- bootloader reads file from us to addr

The kernel decompressor can init kaslr with only one of the two
properties populated.  If both properties are present, then the
decompressor can extract a u64 from userspace-seed and mix it with
hwrng-seed before use.

The small devicetree portion of my brain feels like 'kaslr-seed' is
telling the OS what to do with the value.  Whereas devicetree is
supposed to be describing the hardware.  Or, in this case, describing
the source of the data.

Given that more entropy from more sources is useful for random.c a bit
later in the boot process, it might be worth making hwrng-seed larger
than u64 as well.  This way we can potentially seed random.c from two
sources *before* init even starts.  Without having to depend on the
kernel's hw-rng driver being probed.  After all, it might not have been
built, or it could be a module that's loaded later.

I've attached a draft patch to chosen.txt.

thx,

Jason.


--------------->8---------------------------------
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 6ae9d82d4c37..61f15f04bc0a 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -45,6 +45,52 @@ on PowerPC "stdout" if "stdout-path" is not found.  However, the
 "linux,stdout-path" and "stdout" properties are deprecated. New platforms
 should only use the "stdout-path" property.
 
+random-seed properties
+----------------------
+
+The goal of these properties are to provide an entropy seed early in the boot
+process.  Typically, this is needed by the kernel decompressor for
+initializing KASLR.  At that point, the kernel entropy pools haven't been
+initialized yet, and any hardware rng drivers haven't been loaded yet, if they
+exist.
+
+The bootloader can attain these seeds and pass them to the kernel via the
+respective properties.  The bootloader is not expected to mix or condition
+this data in any way, simply read and pass.  Either one or both properties can
+be set if the data is available.
+
+random-seed,hwrng property
+--------------------------
+
+For bootloaders with support for reading from the system's hardware random
+number generator.  The bootloader can read a chunk of data from the hw-rng
+and set it as the value for this binary blob property.
+
+/ {
+	chosen {
+		random-seed,hwrng = <0x1f 0x07 0x4d 0x91 ...>;
+	};
+};
+
+random-seed,userspace property
+------------------------------
+
+The goal of this property is to also provide backwards compatibility with
+existing systems.  The bootloaders on these deployed systems typically lack
+the ability to edit a devicetree or read from an hwrng.  The only requirement
+for a bootloader is that it be able to read a seed file generated by the
+previous boot into a pre-determined physical address and size.  This is
+typically done via boot scripting.
+
+This property can then be set in the devicetree statically and parsed by a
+modern kernel without requiring a bootloader update.
+
+/ {
+	chosen {
+		random-seed,userspace = <0x40000 0x200>;
+	};
+};
+
 linux,booted-from-kexec
 -----------------------
 

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

#1430887 — Re: devicetree random-seed properties, was: "Re: [PATCH v7 0/9] x86/mm: memory area address KASLR"

On Fri, Jun 24, 2016 at 9:02 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> Thomas,
>
> Sorry for wandering off the topic of your series.  The big take away for
> me is that you and Kees are concerned about x86 systems pre-RDRAND.
> Just as I'm concerned about deployed embedded systems without bootloader
> support for hw-rngs and so forth.
>
> Whatever final form the approach takes for ARM/dt, I'll make sure we can
> extend it to legacy x86 systems.

Yeah, this seems like a productive conversation to me. :)

> Ard,
>
> On Fri, Jun 24, 2016 at 12:54:01PM +0200, Ard Biesheuvel wrote:
>> On 24 June 2016 at 03:11, Jason Cooper <jason@lakedaemon.net> wrote:
>> > On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
> ...
>> >> On arm64, only DT is used for KASLR (even when booting via ACPI). My
>> >> first draft used register x1, but this turned out to be too much of a
>> >> hassle, since parsing the DT is also necessary to discover whether
>> >> there is a 'nokaslr' argument on the kernel command line. So the
>> >> current implementation only supports a single method, which is the
>> >> /chosen/kaslr-seed uint64 property.
>> >
>> > Ok, just to clarify (after a short offline chat), my goal is to set a
>> > userspace,random-seed <addr, len> property in the device tree once.
>> > The bootloader scripts would also only need to be altered once.
>> >
>> > Then, at each boot, the bootloader reads the entirety of
>> > /var/lib/misc/random-seed (512 bytes) into the configured address.
>> > random-seed could be in /boot, or on a flash partition.
>> >
>> > The decompressor would consume a small portion of that seed for kaslr
>> > and such.  After that, the rest would be consumed by random.c to
>> > initialize the entropy pools.
>> >
>>
>> I see. This indeed has little to do with the arm64 KASLR case, other
>> than that they both use a DT property.
>>
>> In the arm64 KASLR case, I deliberately chose to leave it up to the
>> bootloader/firmware to roll the dice, for the same reason you pointed
>> out, i.e., that there is no architected way on ARM to obtain random
>> bits. So in that sense, what you are doing is complimentary to my
>> work, and a KASLR  aware arm64 bootloader would copy some of its
>> random bits taken from /var/lib/misc/random-seed into the
>> /chosen/kaslr-seed DT property.
>
> Here I disagree.  We have two distinct entropy sources; the hw-rng
> currently feeding kaslr via the /chosen/kaslr-seed property, and the
> seasoned userspace seed I propose handed in via an extra property.
>
> Having the bootloader conflate those two sources as if they are equal
> seems to muddy the waters.  I prefer to have bootloaders tell me where
> they got the data rather than to hope the bootloader sourced and mixed
> it well.
>
>> Note that, at the moment, this DT property is only an internal
>> contract between the kernel's UEFI stub and the kernel proper, so we
>> could still easily change that if necessary.
>
> Ideally, I'd prefer to be deliberate with the DT properties, e.g.
>
> random-seed,hwrng     <--- bootloader reads from hw-rng
> random-seed,userspace <--- bootloader reads file from us to addr
>
> The kernel decompressor can init kaslr with only one of the two
> properties populated.  If both properties are present, then the
> decompressor can extract a u64 from userspace-seed and mix it with
> hwrng-seed before use.
>
> The small devicetree portion of my brain feels like 'kaslr-seed' is
> telling the OS what to do with the value.  Whereas devicetree is
> supposed to be describing the hardware.  Or, in this case, describing
> the source of the data.
>
> Given that more entropy from more sources is useful for random.c a bit
> later in the boot process, it might be worth making hwrng-seed larger
> than u64 as well.  This way we can potentially seed random.c from two
> sources *before* init even starts.  Without having to depend on the
> kernel's hw-rng driver being probed.  After all, it might not have been
> built, or it could be a module that's loaded later.
>
> I've attached a draft patch to chosen.txt.
>
> thx,
>
> Jason.
>
>
> --------------->8---------------------------------
> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> index 6ae9d82d4c37..61f15f04bc0a 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -45,6 +45,52 @@ on PowerPC "stdout" if "stdout-path" is not found.  However, the
>  "linux,stdout-path" and "stdout" properties are deprecated. New platforms
>  should only use the "stdout-path" property.
>
> +random-seed properties
> +----------------------
> +
> +The goal of these properties are to provide an entropy seed early in the boot
> +process.  Typically, this is needed by the kernel decompressor for
> +initializing KASLR.  At that point, the kernel entropy pools haven't been
> +initialized yet, and any hardware rng drivers haven't been loaded yet, if they
> +exist.
> +
> +The bootloader can attain these seeds and pass them to the kernel via the
> +respective properties.  The bootloader is not expected to mix or condition
> +this data in any way, simply read and pass.  Either one or both properties can
> +be set if the data is available.
> +
> +random-seed,hwrng property
> +--------------------------
> +
> +For bootloaders with support for reading from the system's hardware random
> +number generator.  The bootloader can read a chunk of data from the hw-rng
> +and set it as the value for this binary blob property.

As in the boot loader would change the value per-boot?

Does this proposal include replacing /chosen/kaslr-seed with
random-seed,hwrng? (Should the "chosen" path be used for hwrng too?)

> +
> +/ {
> +       chosen {
> +               random-seed,hwrng = <0x1f 0x07 0x4d 0x91 ...>;
> +       };
> +};
> +
> +random-seed,userspace property
> +------------------------------
> +
> +The goal of this property is to also provide backwards compatibility with
> +existing systems.  The bootloaders on these deployed systems typically lack
> +the ability to edit a devicetree or read from an hwrng.  The only requirement
> +for a bootloader is that it be able to read a seed file generated by the
> +previous boot into a pre-determined physical address and size.  This is
> +typically done via boot scripting.

What happens on a cold boot?

> +
> +This property can then be set in the devicetree statically and parsed by a
> +modern kernel without requiring a bootloader update.
> +
> +/ {
> +       chosen {
> +               random-seed,userspace = <0x40000 0x200>;
> +       };
> +};
> +
>  linux,booted-from-kexec
>  -----------------------
>

I'm a DT newbie still, so please ignore me if I'm not making useful comments. :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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

#1430940 — Re: devicetree random-seed properties, was: "Re: [PATCH v7 0/9] x86/mm: memory area address KASLR"

On Fri, Jun 24, 2016 at 12:04 PM, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Jun 24, 2016 at 9:02 AM, Jason Cooper <jason@lakedaemon.net> wrote:
>> Thomas,
>>
>> Sorry for wandering off the topic of your series.  The big take away for
>> me is that you and Kees are concerned about x86 systems pre-RDRAND.
>> Just as I'm concerned about deployed embedded systems without bootloader
>> support for hw-rngs and so forth.
>>
>> Whatever final form the approach takes for ARM/dt, I'll make sure we can
>> extend it to legacy x86 systems.
>
> Yeah, this seems like a productive conversation to me. :)

I have an old patch and spec I need to dust off that does this during
*very* early boot on x86 using MSRs so that kASLR can use it.

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

#1434867 — Re: devicetree random-seed properties, was: "Re: [PATCH v7 0/9] x86/mm: memory area address KASLR"

On Fri, Jun 24, 2016 at 01:40:41PM -0700, Andy Lutomirski wrote:
> On Fri, Jun 24, 2016 at 12:04 PM, Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Jun 24, 2016 at 9:02 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> >> Thomas,
> >>
> >> Sorry for wandering off the topic of your series.  The big take away for
> >> me is that you and Kees are concerned about x86 systems pre-RDRAND.
> >> Just as I'm concerned about deployed embedded systems without bootloader
> >> support for hw-rngs and so forth.
> >>
> >> Whatever final form the approach takes for ARM/dt, I'll make sure we can
> >> extend it to legacy x86 systems.
> >
> > Yeah, this seems like a productive conversation to me. :)
> 
> I have an old patch and spec I need to dust off that does this during
> *very* early boot on x86 using MSRs so that kASLR can use it.

I'd love to see that. ;-)

thx,

Jason.

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

#1434869 — Re: devicetree random-seed properties, was: "Re: [PATCH v7 0/9] x86/mm: memory area address KASLR"

Hi Kees,

On Fri, Jun 24, 2016 at 12:04:32PM -0700, Kees Cook wrote:
> On Fri, Jun 24, 2016 at 9:02 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > Thomas,
> >
> > Sorry for wandering off the topic of your series.  The big take away for
> > me is that you and Kees are concerned about x86 systems pre-RDRAND.
> > Just as I'm concerned about deployed embedded systems without bootloader
> > support for hw-rngs and so forth.
> >
> > Whatever final form the approach takes for ARM/dt, I'll make sure we can
> > extend it to legacy x86 systems.
> 
> Yeah, this seems like a productive conversation to me. :)
> 
> > Ard,
> >
> > On Fri, Jun 24, 2016 at 12:54:01PM +0200, Ard Biesheuvel wrote:
> >> On 24 June 2016 at 03:11, Jason Cooper <jason@lakedaemon.net> wrote:
> >> > On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
> > ...
> >> >> On arm64, only DT is used for KASLR (even when booting via ACPI). My
> >> >> first draft used register x1, but this turned out to be too much of a
> >> >> hassle, since parsing the DT is also necessary to discover whether
> >> >> there is a 'nokaslr' argument on the kernel command line. So the
> >> >> current implementation only supports a single method, which is the
> >> >> /chosen/kaslr-seed uint64 property.
> >> >
> >> > Ok, just to clarify (after a short offline chat), my goal is to set a
> >> > userspace,random-seed <addr, len> property in the device tree once.
> >> > The bootloader scripts would also only need to be altered once.
> >> >
> >> > Then, at each boot, the bootloader reads the entirety of
> >> > /var/lib/misc/random-seed (512 bytes) into the configured address.
> >> > random-seed could be in /boot, or on a flash partition.
> >> >
> >> > The decompressor would consume a small portion of that seed for kaslr
> >> > and such.  After that, the rest would be consumed by random.c to
> >> > initialize the entropy pools.
> >> >
> >>
> >> I see. This indeed has little to do with the arm64 KASLR case, other
> >> than that they both use a DT property.
> >>
> >> In the arm64 KASLR case, I deliberately chose to leave it up to the
> >> bootloader/firmware to roll the dice, for the same reason you pointed
> >> out, i.e., that there is no architected way on ARM to obtain random
> >> bits. So in that sense, what you are doing is complimentary to my
> >> work, and a KASLR  aware arm64 bootloader would copy some of its
> >> random bits taken from /var/lib/misc/random-seed into the
> >> /chosen/kaslr-seed DT property.
> >
> > Here I disagree.  We have two distinct entropy sources; the hw-rng
> > currently feeding kaslr via the /chosen/kaslr-seed property, and the
> > seasoned userspace seed I propose handed in via an extra property.
> >
> > Having the bootloader conflate those two sources as if they are equal
> > seems to muddy the waters.  I prefer to have bootloaders tell me where
> > they got the data rather than to hope the bootloader sourced and mixed
> > it well.
> >
> >> Note that, at the moment, this DT property is only an internal
> >> contract between the kernel's UEFI stub and the kernel proper, so we
> >> could still easily change that if necessary.
> >
> > Ideally, I'd prefer to be deliberate with the DT properties, e.g.
> >
> > random-seed,hwrng     <--- bootloader reads from hw-rng
> > random-seed,userspace <--- bootloader reads file from us to addr
> >
> > The kernel decompressor can init kaslr with only one of the two
> > properties populated.  If both properties are present, then the
> > decompressor can extract a u64 from userspace-seed and mix it with
> > hwrng-seed before use.
> >
> > The small devicetree portion of my brain feels like 'kaslr-seed' is
> > telling the OS what to do with the value.  Whereas devicetree is
> > supposed to be describing the hardware.  Or, in this case, describing
> > the source of the data.
> >
> > Given that more entropy from more sources is useful for random.c a bit
> > later in the boot process, it might be worth making hwrng-seed larger
> > than u64 as well.  This way we can potentially seed random.c from two
> > sources *before* init even starts.  Without having to depend on the
> > kernel's hw-rng driver being probed.  After all, it might not have been
> > built, or it could be a module that's loaded later.
> >
> > I've attached a draft patch to chosen.txt.
> >
> > thx,
> >
> > Jason.
> >
> >
> > --------------->8---------------------------------
> > diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> > index 6ae9d82d4c37..61f15f04bc0a 100644
> > --- a/Documentation/devicetree/bindings/chosen.txt
> > +++ b/Documentation/devicetree/bindings/chosen.txt
> > @@ -45,6 +45,52 @@ on PowerPC "stdout" if "stdout-path" is not found.  However, the
> >  "linux,stdout-path" and "stdout" properties are deprecated. New platforms
> >  should only use the "stdout-path" property.
> >
> > +random-seed properties
> > +----------------------
> > +
> > +The goal of these properties are to provide an entropy seed early in the boot
> > +process.  Typically, this is needed by the kernel decompressor for
> > +initializing KASLR.  At that point, the kernel entropy pools haven't been
> > +initialized yet, and any hardware rng drivers haven't been loaded yet, if they
> > +exist.
> > +
> > +The bootloader can attain these seeds and pass them to the kernel via the
> > +respective properties.  The bootloader is not expected to mix or condition
> > +this data in any way, simply read and pass.  Either one or both properties can
> > +be set if the data is available.
> > +
> > +random-seed,hwrng property
> > +--------------------------
> > +
> > +For bootloaders with support for reading from the system's hardware random
> > +number generator.  The bootloader can read a chunk of data from the hw-rng
> > +and set it as the value for this binary blob property.
> 
> As in the boot loader would change the value per-boot?

Yes-ish.  It's an opaque binary blob to the bootloader, but it does update
the devicetree at each boot.

This differs from the userspace approach because bootloaders supporting
devicetree (passing and updating) pre-date bootloader drivers for rngs.
So, if it can read from the hw rng, then it almost certainly can update
the devicetree.  Which is the preferred method for passing data in
devicetree world.

> Does this proposal include replacing /chosen/kaslr-seed with
> random-seed,hwrng? (Should the "chosen" path be used for hwrng too?)

Well, that's up to Ard.  ;-)  I'm simply trying to put my thoughts into
concrete terms for consideration.  If Ard and others are amenable to it,
then yes.  A kernel supporting reading seeds from these proposed DT
properties would not need kaslr-seed.

My objection to /chosen/kaslr-seed is that it doesn't follow the mantra
of DT; state what the object is, not how you think the OS should use it.
Second, by only feeding in enough entropy for seeding kaslr, we are
missing the opportunity to provide sufficient entropy for seeding the
system entropy pools before init is called.

If we need to add this code to support kaslr seeding (we do), then we
may as well solve initializing the system entropy pools while we are
here.  The increased maintenance burden should be negligible.

> > +
> > +/ {
> > +       chosen {
> > +               random-seed,hwrng = <0x1f 0x07 0x4d 0x91 ...>;
> > +       };
> > +};
> > +
> > +random-seed,userspace property
> > +------------------------------
> > +
> > +The goal of this property is to also provide backwards compatibility with
> > +existing systems.  The bootloaders on these deployed systems typically lack
> > +the ability to edit a devicetree or read from an hwrng.  The only requirement
> > +for a bootloader is that it be able to read a seed file generated by the
> > +previous boot into a pre-determined physical address and size.  This is
> > +typically done via boot scripting.
> 
> What happens on a cold boot?

Nothing different.  As long as the OS wrote a new seed blob to the known
location in the filesystem (traditionally /var/lib/misc/random-seed),
then the bootloader should read it in to RAM and then proceed with the
normal boot process.

I resisted calling out /var/lib/misc/random-seed specifically because a
lot of older bootloaders only have support for reading from FAT32 or,
worst case, flash.

In the FAT32-only scenario, most OSes will put the kernel and initrd on
a separate FAT32 partition (usually /boot) for the bootloader to read
from.  So, the bootloader can read /boot/random-seed into the RAM
address before executing the kernel.  /var/lib/misc/random-seed can be a
symlink to /boot, or the init scripts can be modified to write to both
locations.

> > +
> > +This property can then be set in the devicetree statically and parsed by a
> > +modern kernel without requiring a bootloader update.
> > +
> > +/ {
> > +       chosen {
> > +               random-seed,userspace = <0x40000 0x200>;
> > +       };
> > +};
> > +
> >  linux,booted-from-kexec
> >  -----------------------
> >

thx,

Jason.

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web