Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Jun 2016 12:58:00 -0700
From: Kees Cook <>
To: Jason Cooper <>, Ard Biesheuvel <>
Cc: Thomas Garnier <>, 
	"" <>, Ingo Molnar <>, 
	Andy Lutomirski <>, "" <>, Borislav Petkov <>, 
	Baoquan He <>, Yinghai Lu <>, Juergen Gross <>, 
	Matt Fleming <>, Toshi Kani <>, 
	Andrew Morton <>, Dan Williams <>, 
	"Kirill A. Shutemov" <>, Dave Hansen <>, 
	Xiao Guangrong <>, 
	Martin Schwidefsky <>, 
	"Aneesh Kumar K.V" <>, 
	Alexander Kuleshov <>, Alexander Popov <>, 
	Dave Young <>, Joerg Roedel <>, Lv Zheng <>, 
	Mark Salter <>, Dmitry Vyukov <>, 
	Stephen Smalley <>, Boris Ostrovsky <>, 
	Christian Borntraeger <>, Jan Beulich <>, 
	LKML <>, Jonathan Corbet <>, 
	"" <>
Subject: Re: [PATCH v7 0/9] x86/mm: memory area address KASLR

On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper <> 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 <> wrote:
>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper <> 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

> 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 Cook
Chrome OS & Brillo Security

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.