mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sandy Harris <sandyinchina@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
	Sandy Harris <sandyinchina@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-crypto@vger.kernel.org,
	Stephan Mueller <smueller@chronox.de>
Subject: Re: [PATCH][RFC] CPU Jitter random number generator (resent)
Date: Tue, 21 May 2013 17:39:49 -0400	[thread overview]
Message-ID: <CACXcFmnyDh7kBN3SCLGH3DcHH2gZO2_7weL_pch00g+3Jsjegg@mail.gmail.com> (raw)
In-Reply-To: <20130521190157.GD22559@thunk.org>

On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o <tytso@mit.edu> wrote:

> I continue to be suspicious about claims that userspace timing
> measurements are measuring anything other than OS behaviour.

Yes, but they do seem to contain some entropy. See links in the
original post of this thread, the havege stuff and especially the
McGuire et al paper.

>  But that
> doesn't mean that they shouldn't exist.  Personally, I believe you
> should try to collect as much entropy as you can, from as many places
> as you can.

Yes.

>  For VM's, it means we should definitely use
> paravirtualization to get randomness from the host OS.

Yes, I have not worked out the details but it seems clear that
something along those lines would be a fine idea.

> For devices like Linux routers, what we desperately need is hardware
> assist;  [or] mix
> in additional timing information either at kernel device driver level,
> or from systems such as HAVEGE.
>
> What I'm against is relying only on solutions such as HAVEGE or
> replacing /dev/random with something scheme that only relies on CPU
> timing and ignores interrupt timing.

My question is how to incorporate some of that into /dev/random.
At one point, timing info was used along with other stuff. Some
of that got deleted later, What is the current state? Should we
add more?

--
Who put a stop payment on my reality check?

  reply	other threads:[~2013-05-21 21:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-21  6:44 Stephan Mueller
2013-05-21 16:43 ` Sandy Harris
     [not found] ` <CACXcFmmPjGBYhfbwfMdE2iTv2a9Q6HB1aT8JSnXA-8n2yO0zcA@mail.gmail.com>
2013-05-21 16:56   ` Stephan Mueller
     [not found] ` <CACXcFm=PCPs23Kd8B0+B7418fSaz=59Z4DRcj3-Wcd-i=Meang@mail.gmail.com>
2013-05-21 19:01   ` Theodore Ts'o
2013-05-21 21:39     ` Sandy Harris [this message]
2013-05-22  6:20       ` Stephan Mueller
2013-05-22 17:40         ` Sandy Harris
2013-05-22 18:34           ` Stephan Mueller
2013-05-23  9:59             ` Stephan Mueller
2013-08-05  3:05       ` Stephan Mueller

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=CACXcFmnyDh7kBN3SCLGH3DcHH2gZO2_7weL_pch00g+3Jsjegg@mail.gmail.com \
    --to=sandyinchina@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smueller@chronox.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®