All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jiri Slaby <jirislaby@gmail.com>,
	linux-kernel@vger.kernel.org, tytso@mit.edu
Subject: Re: mmotm 2008-12-01-19-41: early exception (page fault -- deref of 0x20)
Date: Wed, 03 Dec 2008 11:07:00 -0600	[thread overview]
Message-ID: <1228324020.3255.24.camel@calx> (raw)
In-Reply-To: <4935C9CC.8070308@linux.intel.com>

On Tue, 2008-12-02 at 15:50 -0800, Arjan van de Ven wrote: 
> Matt Mackall wrote:
> > 
> > If we oops or warn while picking a timesource, we'll have lots of fun?
> > 
> 
> we really only need to mix in the tsc; ktime_get() is just an arch friendly way to get that
> I supposed (wrongly).
> 
> but yes we need to do a few things
> 1) seed on demand with a platform time source

Currently we use jiffies + get_cycles(). That's going to have somewhere
between, oh, 3 bits of entropy (very stable boot with only jiffies) and
25 bits of entropy (TSC with lots of waiting for hardware) at boot. 
Ideally, we'd have access to a wall clock of some sort as well. But
that's also a fairly limited source - wall clocks are both low
resolution and predictable/collision-prone.

> 2) have a way where arch init can just hand semi random data during the boot process to
>     increase the randomness (even if it doesn't count as entropy)

A simple wrapper around mix_pool_bytes probably fits the ticket.

But I don't think this will solve the general problem of 'large numbers
of practically identical machines booting up with the same pre-init
random number pools'. Beyond things like MAC addresses and serial
numbers (predictable/observable but at least not collision-prone), we
have no way to differentiate some boxes. We may need to forcibly
generate some timing entropy. Perhaps something like this:

http://markmail.org/message/xwsbywr6ziil2qu2

(which is way too slow in its current form)

There's a related problem of systems with no way to store a seed across
boots.

-- 
Mathematics is the supreme nostalgia of our time.


  reply	other threads:[~2008-12-03 17:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-02 23:09 mmotm 2008-12-01-19-41: early exception (page fault -- deref of 0x20) Jiri Slaby
2008-12-02 23:29 ` Matt Mackall
2008-12-02 23:33 ` Andrew Morton
2008-12-02 23:42   ` Matt Mackall
2008-12-02 23:50     ` Arjan van de Ven
2008-12-03 17:07       ` Matt Mackall [this message]
2008-12-03 17:14         ` Arjan van de Ven
2008-12-03 13:00   ` Jiri Kosina
2008-12-22 12:04     ` Jiri Slaby
2008-12-22 12:25       ` Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1228324020.3255.24.camel@calx \
    --to=mpm@selenic.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.