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 20:16:03 +0000
From: Jason Cooper <>
Cc: Kees Cook <>, 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

Hey Sandy,

On Thu, Jun 23, 2016 at 03:45:54PM -0400, Sandy Harris wrote:
> Jason Cooper <> 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:

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.



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

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.