From: Andy Lutomirski <luto@amacapital.net>
To: Kurt Roeckx <kurt@roeckx.be>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
Stephan Mueller <smueller@chronox.de>,
Andy Lutomirski <luto@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Kees Cook <keescook@chromium.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
"Ahmed S. Darwish" <darwish.07@gmail.com>,
Lennart Poettering <mzxreary@0pointer.de>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"Alexander E. Patrakov" <patrakov@gmail.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Willy Tarreau <w@1wt.eu>, Matthew Garrett <mjg59@srcf.ucam.org>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
linux-man <linux-man@vger.kernel.org>
Subject: Re: [PATCH v3 0/8] Rework random blocking
Date: Thu, 9 Jan 2020 14:30:48 -1000 [thread overview]
Message-ID: <99CB981B-752C-449B-98BE-A4DF80D25A26@amacapital.net> (raw)
In-Reply-To: <20200109220230.GA39185@roeckx.be>
> On Jan 9, 2020, at 12:02 PM, Kurt Roeckx <kurt@roeckx.be> wrote:
>
>
> If the kernel provides a good RNG, the only reason I can see why
> you would like to have direct access to a hwrng is to verify that
> it's working correctly. That might mean that you put it in some
> special mode where it returns raw unprocessed values. If the device
> is in such a mode, it's output will not provide the same entropy
> per bit, and so I would expect the kernel to stop using it directly.
I disagree.
If I buy a ChaosKey or a fancy EAL4FIPSOMG key, I presumably have it for a reason and I want to actually use the thing for real. Maybe it’s for some certification reason and maybe it’s just because it’s really cool.
As for “direct” access, I think AMD provides an interface to read raw output from the on-die entropy source. Exposing this to user space is potentially quite useful for anyone who wants to try to characterize it. I don’t really think people should use a raw sample interface as a source of production random numbers, though.
prev parent reply other threads:[~2020-01-10 0:30 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-23 8:20 [PATCH v3 0/8] Rework random blocking Andy Lutomirski
2019-12-23 8:20 ` [PATCH v3 1/8] random: Don't wake crng_init_wait when crng_init == 1 Andy Lutomirski
2020-01-07 20:42 ` Theodore Y. Ts'o
2019-12-23 8:20 ` [PATCH v3 2/8] random: Add a urandom_read_nowait() for random APIs that don't warn Andy Lutomirski
2020-01-07 20:43 ` Theodore Y. Ts'o
2019-12-23 8:20 ` [PATCH v3 3/8] random: Add GRND_INSECURE to return best-effort non-cryptographic bytes Andy Lutomirski
2020-01-07 20:44 ` Theodore Y. Ts'o
2019-12-23 8:20 ` [PATCH v3 4/8] random: Ignore GRND_RANDOM in getentropy(2) Andy Lutomirski
2020-01-07 20:44 ` Theodore Y. Ts'o
2019-12-23 8:20 ` [PATCH v3 5/8] random: Make /dev/random be almost like /dev/urandom Andy Lutomirski
2020-01-07 21:02 ` Theodore Y. Ts'o
2019-12-23 8:20 ` [PATCH v3 6/8] random: Remove the blocking pool Andy Lutomirski
2020-01-07 21:03 ` Theodore Y. Ts'o
2019-12-23 8:20 ` [PATCH v3 7/8] random: Delete code to pull data into pools Andy Lutomirski
2020-01-07 21:03 ` Theodore Y. Ts'o
2019-12-23 8:20 ` [PATCH v3 8/8] random: Remove kernel.random.read_wakeup_threshold Andy Lutomirski
2020-01-07 21:04 ` Theodore Y. Ts'o
2019-12-26 9:29 ` [PATCH v3 0/8] Rework random blocking Stephan Müller
2019-12-26 10:03 ` Matthew Garrett
2019-12-26 11:40 ` Stephan Mueller
2019-12-26 11:12 ` Andy Lutomirski
2019-12-26 12:03 ` Stephan Mueller
2019-12-26 12:46 ` Andy Lutomirski
2019-12-27 9:55 ` Stephan Mueller
2019-12-26 14:04 ` Theodore Y. Ts'o
2019-12-26 23:29 ` Andy Lutomirski
2019-12-27 10:29 ` Stephan Mueller
2019-12-27 13:04 ` Theodore Y. Ts'o
2019-12-27 21:22 ` Stephan Mueller
2019-12-27 22:08 ` Theodore Y. Ts'o
2019-12-28 2:06 ` Andy Lutomirski
2019-12-29 14:49 ` Theodore Y. Ts'o
2019-12-29 15:08 ` Andy Lutomirski
2019-12-28 7:01 ` Willy Tarreau
2020-01-09 22:02 ` Kurt Roeckx
2020-01-09 22:40 ` Theodore Y. Ts'o
2020-01-09 23:02 ` Kurt Roeckx
2020-01-10 7:53 ` Stephan Mueller
2020-01-10 0:30 ` Andy Lutomirski [this message]
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=99CB981B-752C-449B-98BE-A4DF80D25A26@amacapital.net \
--to=luto@amacapital.net \
--cc=Jason@zx2c4.com \
--cc=darwish.07@gmail.com \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=kurt@roeckx.be \
--cc=linux-api@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=mtk.manpages@gmail.com \
--cc=mzxreary@0pointer.de \
--cc=patrakov@gmail.com \
--cc=smueller@chronox.de \
--cc=tytso@mit.edu \
--cc=w@1wt.eu \
/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).