linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Stephan Mueller <smueller@chronox.de>
Cc: Jeff Epler <jepler@unpythonic.net>,
	linux-crypto@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput
Date: Sun, 10 Feb 2013 19:05:39 -0500	[thread overview]
Message-ID: <20130211000539.GC10801@thunk.org> (raw)
In-Reply-To: <5117F5D5.8040709@chronox.de>

On Sun, Feb 10, 2013 at 08:32:37PM +0100, Stephan Mueller wrote:
> 
> Given all your doubts on the high-precision timer, how can you
> reasonably state that the Linux kernel RNG is good then?

Because we're measuring intervals that are substantially larger than
"CPU jitter".  (i.e., inputs from keyboards and mice, interrupts from
hard drives and networks, etc.)

> The data from add_timer_randomness the kernel feeds into the input_pool
> is a concatenation of the event value, the jiffies and the get_cycles()
> value. The events hardly contains any entropy, the jiffies a little bit
> due to the coarse resolution of 250 or 1000 Hz. Only the processor
> cycles value provides real entropy.

Jiffies is defined by 250HZ (4ms) on modern Linux kernels, at least
for x86 systems.  Average seek times for common HDD's are 10ms, with
full-stroke seek times being roughly twice that, and seek times
perhaps 50% slower for laptop/mobile HDD's, and 50% faster for
high-end server drives.  So that's enough to get maybe a bit or two
worth's of entropy for HDD interrupts.

(Yes, this does imply that the entropy estimator for /dev/random is
probably overestimating the entropy in a number of cases; in general,
it's actually pretty difficult to measure entropy accurately in an
automated way.)

> Moreover, I cannot understand your comments on VMs -- on x86, the timer
> depends on the rdtsc instruction which should be available on current
> CPUs and is callable from user space. Hence, there should be no obstacle
> to use this instruction within a VM and get a good reading.

The problem is one of correctness versus performance.  (The TSC is
unsynchronized across different CPU cores, and the guest OS has no
idea when it gets switched to running on a different core on the host
CPU.)  As a result, on many/most VM's the TSC is emulated or
paravirtualized.  For example, see:

http://old-list-archives.xen.org/archives/html/xen-devel/2009-08/msg01103.html

for a discussion of the issues involved.

Regards,

						- Ted

  parent reply	other threads:[~2013-02-11  0:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-08 22:04 [RFC][PATCH] Entropy generator with 100 kB/s throughput Stephan Mueller
2013-02-09 18:06 ` Theodore Ts'o
2013-02-10  1:57   ` Jeff Epler
2013-02-10 12:46     ` Stephan Mueller
2013-02-10 15:53       ` Jeff Epler
2013-02-10 18:50       ` Theodore Ts'o
2013-02-10 19:27         ` Sandy Harris
2013-02-10 19:32         ` Stephan Mueller
2013-02-10 21:59           ` Sandy Harris
2013-02-11  0:05           ` Theodore Ts'o [this message]
2013-02-10 12:25   ` Stephan Mueller
2013-02-21 14:07 ` Phil Carmody
2013-02-21 14:17   ` Stephan Mueller
2013-02-21 17:46     ` Sandy Harris
2013-02-21 20:30       ` Theodore Ts'o
     [not found] ` <CAFtRNNzcUpxT3R6ttUJ0c-7QTVRxbwRVq6bPqvkSL93vbstT4g@mail.gmail.com>
2013-02-22 11:14   ` Nick Kossifidis

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=20130211000539.GC10801@thunk.org \
    --to=tytso@mit.edu \
    --cc=jepler@unpythonic.net \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smueller@chronox.de \
    /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).