linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sandy Harris <sandyinchina@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Stephan Mueller <smueller@chronox.de>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-hardening@lists.openwall.com
Subject: Re: get_random_bytes returns bad randomness before seeding is complete
Date: Sat, 3 Jun 2017 17:45:43 -0400	[thread overview]
Message-ID: <CACXcFmndxSpytsndqeEsOsyB-nyx_xwBAaG1PMRUmof4U-rDMw@mail.gmail.com> (raw)
In-Reply-To: <CAHmME9rwKneq0C5GYPSWamGRT0775=-Xw3pyq6uxJXJyyBtr1g@mail.gmail.com>

Stephan's driver, the HAVEGE system & several others purport to
extract entropy from a series of timer calls. Probably the best
analysis is in the Mcguire et al. paper at
https://static.lwn.net/images/conf/rtlws11/random-hardware.pdf & the
simplest code in my user-space driver at
https://github.com/sandy-harris/maxwell The only kernel-space code I
know of is Stephan's.

If the claim that such calls give entropy is accepted (which I think
it should be) then if we get one bit per call, need 100 or so bits &
space the calls 100 ns apart, loading up a decent chunk of startup
entropy takes about 10,000 ns or 10 microseconds which looks like an
acceptable delay. Can we just do that very early in the boot process?

Of course this will fail on systems with no high-res timer. Are there
still some of those? It might be done in about 1000 times as long on a
system that lacks the realtime library's nanosecond timer but has the
Posix standard microsecond timer, implying a delay time in the
milliseconds. Would that be acceptable in those cases?

  reply	other threads:[~2017-06-03 21:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-02 14:59 get_random_bytes returns bad randomness before seeding is complete Jason A. Donenfeld
2017-06-02 15:53 ` Jason A. Donenfeld
2017-06-02 16:48   ` Jason A. Donenfeld
2017-06-02 17:41   ` [kernel-hardening] " Daniel Micay
2017-06-02 17:46     ` Jason A. Donenfeld
2017-06-02 18:58     ` Kees Cook
2017-06-02 17:26 ` Theodore Ts'o
2017-06-02 17:44   ` Jason A. Donenfeld
2017-06-02 19:07     ` Theodore Ts'o
2017-06-02 23:58       ` Jason A. Donenfeld
2017-06-03  0:20         ` [kernel-hardening] " Sandy Harris
2017-06-03  2:32         ` [PATCH RFC 0/3] get_random_bytes seed blocking Jason A. Donenfeld
2017-06-03  2:32           ` [PATCH RFC 1/3] random: add synchronous API for the urandom pool Jason A. Donenfeld
2017-06-03  2:32           ` [PATCH RFC 2/3] random: add get_random_{bytes,u32,u64,int,long}_wait family Jason A. Donenfeld
2017-06-03  2:32           ` [PATCH RFC 3/3] random: warn when kernel uses unseeded randomness Jason A. Donenfeld
2017-06-03  5:04         ` get_random_bytes returns bad randomness before seeding is complete Theodore Ts'o
2017-06-03 12:30           ` Jason A. Donenfeld
2017-06-03 21:45             ` Sandy Harris [this message]
2017-06-03 22:54               ` Jeffrey Walton
2017-06-03 23:55                 ` [kernel-hardening] " Daniel Micay
2017-06-04  5:55                 ` Stephan Müller
2017-06-04  5:48 ` Stephan Müller
2017-06-04  5:54   ` Jeffrey Walton
2017-06-04  6:23 ` Stephan Müller

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=CACXcFmndxSpytsndqeEsOsyB-nyx_xwBAaG1PMRUmof4U-rDMw@mail.gmail.com \
    --to=sandyinchina@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=kernel-hardening@lists.openwall.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;
as well as URLs for NNTP newsgroup(s).