From: Theodore Ts'o <tytso@mit.edu>
To: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/4] random: use device attach events for entropy
Date: Sun, 3 Nov 2013 18:10:04 -0500 [thread overview]
Message-ID: <20131103231004.GD7376@thunk.org> (raw)
In-Reply-To: <1383485595-2020-2-git-send-email-tytso@mit.edu>
On Sun, Nov 03, 2013 at 08:33:12AM -0500, Theodore Ts'o wrote:
> Some investigation from FreeBSD shows that there is entropy available
> from measuring the device attach times:
>
> http://lists.randombit.net/pipermail/cryptography/2013-October/005689.html
>
> This will hopefully help us more quickly initialize the entropy pools
> while the system is booting (which is one of the times when we really
> badly need more entropy, especially in the case of the first boot
> after an consumer electronics device is taken out of the box).
>
> Measurements indicate this makes a huge improvement in the security of
> /dev/urandom during the boot sequence, so I'm cc'ing this to the
> stable kernel series. Especially for embedded systems, which use
> flash and which don't necessarily have the network enabled when they
> first generate ssh or x.509 keys (sigh), this can be a big deal.
>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> Cc: stable@vger.kernel.org
Self-NAK. After doing some more measurements, I'm not convinced the
entropy estimator is working well given how we are collecting the
device attach times. Instead, we need to measure the delta between
the start and the end of the device probe, which in turn will only
work if we have a valid cycle counter. (random_get_entropy() is not
going to cut it.)
So with some changes, this approach will improve things on x86, but on
architectures like ARM, which generally don't have a cycle counter,
the jiffies counter is not going to have enough resolution to do
something useful --- and it was on platforms such as ARM and MIPS
where I was hoping this would be most useful. Grumble.
Why can't ARM and MIPS have decent cycle counters? <Shakes fist>
- Ted
next prev parent reply other threads:[~2013-11-03 23:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-03 13:33 [PATCH 0/4] random: improve entropy pool initialization at boot time Theodore Ts'o
2013-11-03 13:33 ` [PATCH 1/4] random: use device attach events for entropy Theodore Ts'o
2013-11-03 14:51 ` Greg KH
2013-11-03 18:44 ` Theodore Ts'o
2013-11-03 23:10 ` Theodore Ts'o [this message]
2013-11-03 13:33 ` [PATCH 2/4] random: make add_timer_randomness() fill the nonblocking pool first Theodore Ts'o
2013-11-03 13:33 ` [PATCH 3/4] random: printk notifications for urandom pool initialization Theodore Ts'o
2013-11-03 13:33 ` [PATCH 4/4] random: don't zap entropy count in rand_initialize() Theodore Ts'o
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=20131103231004.GD7376@thunk.org \
--to=tytso@mit.edu \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).