From: Torsten Duwe <duwe@lst.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
"Theodore Ts'o" <tytso@mit.edu>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Matt Mackall <mpm@selenic.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Arnd Bergmann <arnd@arndb.de>,
Rusty Russell <rusty@rustcorp.com.au>,
Satoru Takeuchi <satoru.takeuchi@gmail.com>,
ingo.tuchscherer@de.ibm.com, linux-kernel@vger.kernel.org,
Hans-Georg Markgraf <MGRF@de.ibm.com>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Joe Perches <joe@perches.com>
Subject: [PATCH v3 00/03]: hwrng: an in-kernel rngd
Date: Mon, 14 Apr 2014 18:02:11 +0200 [thread overview]
Message-ID: <20140414160211.GE711@lst.de> (raw)
In-Reply-To: <158d2776-1ea4-4f32-a9e9-0488047e6b70@email.android.com>
More or less a resend of v2.
On Wed, Mar 26, 2014 at 06:03:37PM -0700, H. Peter Anvin wrote:
> I'm wondering more about the default. We default to 50% for arch_get_random_seed, and this is supposed to be the default for in effect unverified hwrngs...
Done. 50% is now the default, that's the only change from v2.
Andy: the printk you pointed out already limits itself to 1/10s,
which is half the default rate limit. Also, as Peter already
wrote, we're dealing with true HWRNGs here; if such a device
does not produce a single byte within 10 seconds something _is_
severely broken and, like a dying disk, worth to be logged.
Here's one of the better circuits I found:
http://www.maximintegrated.com/app-notes/index.mvp/id/3469
or offline:
http://pdfserv.maximintegrated.com/en/an/AN3469.pdf
Disclaimer: I'm not endorsing Maxim, it's just that paper
that hits the spot IMHO.
Anything wrong with feeding those bits into the input pool?
Any other comments on the code?
Torsten
next prev parent reply other threads:[~2014-04-14 16:02 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-21 14:29 [PATCH v2 00/03]: khwrngd Torsten Duwe
2014-03-21 14:32 ` [Patch v2 01/03]: provide an injection point for pure hardware randomness Torsten Duwe
2014-03-21 14:33 ` [PATCH v2 02/03]: hwrng: create filler thread Torsten Duwe
2014-03-27 0:50 ` Andy Lutomirski
2014-03-27 1:03 ` H. Peter Anvin
2014-03-27 1:11 ` Andy Lutomirski
2014-03-27 1:55 ` H. Peter Anvin
2014-03-27 4:47 ` H. Peter Anvin
2014-03-27 15:03 ` Torsten Duwe
2014-03-27 16:06 ` Andy Lutomirski
2014-03-27 14:54 ` Torsten Duwe
2014-03-27 15:47 ` Andy Lutomirski
2014-04-14 16:02 ` Torsten Duwe [this message]
2014-04-14 16:04 ` [PATCH v3 01/03]: hwrng: provide an injection point for pure hardware randomness Torsten Duwe
2014-04-14 16:05 ` [PATCH v3 02/03]: hwrng: create filler thread Torsten Duwe
2014-04-14 16:06 ` [PATCH v3 03/03]: hwrng: khwrngd derating per device Torsten Duwe
2014-04-14 16:41 ` Andy Lutomirski
2014-04-15 8:51 ` Torsten Duwe
2014-04-15 16:53 ` Andy Lutomirski
2014-05-27 13:41 ` [PATCH v5 00/03]: hwrng: an in-kernel rngd Torsten Duwe
2014-05-27 13:44 ` [Patch 01/03]: provide an injection point for pure hardware randomness Torsten Duwe
2014-05-27 13:45 ` [Patch v5 02/03]: hwrng: create filler thread Torsten Duwe
2014-05-27 13:46 ` [Patch v5 03/03]: hwrng: khwrngd derating per device Torsten Duwe
2014-05-27 14:11 ` [Patch v5.1 " Torsten Duwe
2014-06-12 1:24 ` H. Peter Anvin
2014-06-12 10:09 ` Torsten Duwe
2014-06-14 2:40 ` Theodore Ts'o
2014-06-14 2:44 ` H. Peter Anvin
2014-06-15 5:11 ` Theodore Ts'o
2014-06-16 7:31 ` Torsten Duwe
2014-06-16 11:22 ` Theodore Ts'o
2014-06-16 14:07 ` Torsten Duwe
2014-06-16 14:40 ` Theodore Ts'o
[not found] ` <20140616141444.GB1744@suse.de>
[not found] ` <20140616142812.GB19387@thunk.org>
2014-07-11 13:43 ` Ingo Tuchscherer
2014-07-11 14:42 ` Theodore Ts'o
2014-04-14 16:09 ` [PATCH v3 00/03]: hwrng: an in-kernel rngd H. Peter Anvin
2014-04-14 16:24 ` Torsten Duwe
2014-04-14 16:29 ` H. Peter Anvin
2014-04-14 16:43 ` Andy Lutomirski
2014-04-14 16:27 ` [PATCH v4 03/03]: hwrng: khwrngd derating per device Torsten Duwe
2014-03-21 14:34 ` [PATCH v2 " Torsten Duwe
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=20140414160211.GE711@lst.de \
--to=duwe@lst.de \
--cc=MGRF@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=gerald.schaefer@de.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=ingo.tuchscherer@de.ibm.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mpm@selenic.com \
--cc=rusty@rustcorp.com.au \
--cc=satoru.takeuchi@gmail.com \
--cc=schwidefsky@de.ibm.com \
--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.