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

Groups > linux.kernel > #1430107

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

Show all headers | View raw

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.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[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

csiph-web