From: "Theodore Ts'o" <tytso@mit.edu>
To: "Stephan Müller" <smueller@chronox.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Jason A. Donenfeld" <jason@zx2c4.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v12 3/4] Linux Random Number Generator
Date: Thu, 20 Jul 2017 23:08:47 -0400 [thread overview]
Message-ID: <20170721030846.m2r3ix4s2modahsw@thunk.org> (raw)
In-Reply-To: <5238256.jqB5BlnSCf@positron.chronox.de>
On Thu, Jul 20, 2017 at 09:00:02PM +0200, Stephan Müller wrote:
> I concur with your rationale where de-facto the correlation is effect is
> diminished and eliminated with the fast_pool and the minimal entropy
> estimation of interrupts.
>
> But it does not address my concern. Maybe I was not clear, please allow me to
> explain it again.
>
> We have lots of entropy in the system which is discarded by the aforementioned
> approach (if a high-res timer is present -- without it all bets are off anyway
> and this should be covered in a separate discussion). At boot time, this issue
> is fixed by injecting 256 interrupts in the CRNG and consider it seeded.
>
> But at runtime, were we still need entropy to reseed the CRNG and to supply /
> dev/random. The accounting of entropy at runtime is much too conservative...
Practically no one uses /dev/random. It's essentially a deprecated
interface; the primary interfaces that have been recommended for well
over a decade is /dev/urandom, and now, getrandom(2). We only need
384 bits of randomness every 5 minutes to reseed the CRNG, and that's
plenty even given the very conservative entropy estimation currently
being used.
This was deliberate. I care a lot more that we get the initial
boot-time CRNG initialization right on ARM32 and MIPS embedded
devices, far, far, more than I care about making plenty of
information-theoretic entropy available at /dev/random on an x86
system. Further, I haven't seen an argument for the use case where
this would be valuable.
If you don't think they count because ARM32 and MIPS don't have a
high-res timer, then you have very different priorities than I do. I
will point out that numerically there are huge number of these devices
--- and very, very few users of /dev/random.
> You mentioned that you are super conservative for interrupts due to timer
> interrupts. In all measurements on the different systems I conducted, I have
> not seen that the timer triggers an interrupt picked up by
> add_interrupt_randomness.
Um, the timer is the largest number of interrupts on my system. Compare:
CPU0 CPU1 CPU2 CPU3
LOC: 6396552 6038865 6558646 6057102 Local timer interrupts
with the number of disk related interrupts:
120: 21492 139284 40513 1705886 PCI-MSI 376832-edge ahci[0000:00:17.0]
... and add_interrupt_randomness() gets called for **every**
interrupt. On an mostly idle machine (I was in meetings most of
today) it's not surprising that time interrupts dominate. That
doesn't matter for me as much because I don't really care about
/dev/random performance. What's is **far** more important is that the
entropy estimations behave correctly, across all of Linux's
architectures, while the kernel is going through startup, before CRNG
is declared initialized.
> As we have no formal model about entropy to begin with, we can only assume and
> hope we underestimate entropy with the entropy heuristic.
Yes, and that's why I use an ultra-conservative estimate. If we start
using a more aggressive hueristic, we open ourselves up to potentially
very severe security bugs --- and for what? What's the cost benefit
ratio here which makes this a worthwhile thing to risk?
> Finally, I still think it is helpful to allow (not mandate) to involve the
> kernel crypto API for the DRNG maintenance (i.e. the supplier for /dev/random
> and /dev/urandom). The reason is that now more and more DRNG implementations
> in hardware pop up. Why not allowing them to be used. I.e. random.c would only
> contain the logic to manage entropy but uses the DRNG requested by a user.
We *do* allow them to be used. And we support a large number of
hardware random number generators already. See drivers/char/hw_random.
BTW, I theorize that this is why the companies that could do the
bootloader random seen work haven't bothered. Most of their products
have a TPM or equivalent, and with modern kernel the hw_random
interface now has a kernel thread that will automatically fill the
/dev/random entropy pool from the hw_random device. So this all works
already, today, without needing a userspace rngd (which used to be
required).
> In addition allowing a replacement of the DRNG component (at compile time at
> least) may get us away from having a separate DRNG solution in the kernel
> crypto API. Some users want their chosen or a standardized DRNG to deliver
> random numbers. Thus, we have several DRNGs in the kernel crypto API which are
> seeded by get_random_bytes. Or in user space, many folks need their own DRNG
> in user space in addition to the kernel. IMHO this is all a waste. If we could
> use the user-requested DRNG when producing random numbers for get_random_bytes
> or /dev/urandom or getrandom.
To be honest, I've never understood why that's there in the crypto API
at all. But adding more ways to switch out the DRNG for /dev/random
doesn't solve that problem; in fact it's moving things in the wrong
direction.
Cheers,
- Ted
next prev parent reply other threads:[~2017-07-21 3:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-18 7:57 [RFC PATCH v12 0/4] /dev/random - a new approach Stephan Müller
2017-07-18 7:57 ` [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible Stephan Müller
2017-07-18 8:30 ` Greg Kroah-Hartman
2017-07-18 8:40 ` Stephan Müller
2017-07-18 8:49 ` Greg Kroah-Hartman
2017-07-18 8:53 ` Stephan Müller
2017-07-18 9:02 ` Arnd Bergmann
2017-07-18 9:10 ` Stephan Müller
2017-07-18 9:16 ` Arnd Bergmann
2017-07-18 9:17 ` Stephan Müller
2017-07-18 7:58 ` [RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG Stephan Müller
2017-07-18 8:13 ` Arnd Bergmann
2017-07-18 8:37 ` Stephan Müller
2017-07-18 8:47 ` Arnd Bergmann
2017-07-18 8:50 ` Stephan Müller
2017-07-18 7:59 ` [RFC PATCH v12 3/4] Linux Random Number Generator Stephan Müller
2017-07-18 8:32 ` Greg Kroah-Hartman
2017-07-18 8:45 ` Stephan Müller
2017-07-18 8:52 ` Greg Kroah-Hartman
2017-07-18 14:37 ` Stephan Müller
2017-07-18 21:08 ` Theodore Ts'o
2017-07-19 1:00 ` Sandy Harris
2017-07-19 1:51 ` Theodore Ts'o
2017-07-19 6:25 ` Stephan Müller
2017-07-30 10:44 ` Pavel Machek
2017-07-23 18:05 ` Sandy Harris
2017-07-23 21:47 ` Theodore Ts'o
2017-07-19 6:22 ` Stephan Müller
2017-07-19 6:34 ` Greg Kroah-Hartman
2017-07-19 17:26 ` Theodore Ts'o
2017-07-20 19:00 ` Stephan Müller
2017-07-21 3:08 ` Theodore Ts'o [this message]
2017-07-21 8:57 ` Stephan Müller
2017-07-21 15:09 ` Arnd Bergmann
2017-07-21 15:17 ` Stephan Müller
2017-07-18 8:52 ` Greg Kroah-Hartman
2017-07-18 7:59 ` [RFC PATCH v12 4/4] LRNG - enable compile Stephan Müller
2017-07-18 8:51 ` Arnd Bergmann
2017-07-18 8:56 ` Stephan Müller
2017-07-21 11:30 [RFC PATCH v12 3/4] Linux Random Number Generator Jeffrey Walton
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=20170721030846.m2r3ix4s2modahsw@thunk.org \
--to=tytso@mit.edu \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=jason@zx2c4.com \
--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).