From: Stephan Mueller <smueller@chronox.de>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>, "David Jaša" <djasa@redhat.com>,
"Andi Kleen" <andi@firstfloor.org>,
sandyinchina@gmail.com,
"Jason Cooper" <cryptography@lakedaemon.net>,
"John Denker" <jsd@av8n.com>,
"H. Peter Anvin" <hpa@linux.intel.com>,
"Joe Perches" <joe@perches.com>, "Pavel Machek" <pavel@ucw.cz>,
"George Spelvin" <linux@horizon.com>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/5] /dev/random - a new approach
Date: Tue, 21 Jun 2016 20:04:32 +0200 [thread overview]
Message-ID: <1900555.p3fYFz9p7D@positron.chronox.de> (raw)
In-Reply-To: <5d1a9ce4-a2e5-4ec7-9ca8-22d75281025f@gmail.com>
Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn:
Hi Austin,
>
> >> 2. Quite a few systems have a rather distressingly low lower bound and
> >> still get accepted by your algorithm (a number of the S/390 systems, and
> >> a handful of the AMD processors in particular).
> >
> > I am aware of that, but please read the entire documentation where the
> > lower and upper boundary comes from and how the Jitter RNG really
> > operates. There you will see that the lower boundary is just that: it
> > will not be lower, but the common case is the upper boundary.
>
> Talking about the common case is all well and good, but the lower bound
> still needs to be taken into account. If the test results aren't
> uniformly distributed within that interval, or even following a typical
> Gaussian distribution within it (which is what I and many other people
> would probably assume without the data later in the appendix), then you
> really need to mention this _before_ the table itself. Such information
> is very important, and not everyone has time to read everything.
Then read chapter 5 as mentioned above the table. What you read was an
appendix that is supposed to supplement to that chapter and not a full-fledged
documentation.
And quickly glancing over that table to make a judgment is not helpful for
such topic.
>
> >> 5. You discount the Pentium Celeron Mobile CPU as old and therefore not
> >> worth worrying about. Linux still runs on 80486 and other 'ancient'
> >> systems, and there are people using it on such systems. You need to
> >> account for this usage.
> >
> > I do not account for that in the documentation. In real life though, I
> > certainly do -- see how the Jitter RNG is used in the kernel.
>
> Then you shouldn't be pushing the documentation as what appears to be
> your sole argument for including it in the kernel.
I understand you read Appendix F -- but that document is 150+ pages in size
with quite a bit of information and you judge it based on an appendix
providing supplemental data?
Note, I pointed you to this appendix at the starting question where you wanted
to see test results on execution timing variations on ARM and MIPS.
>
> >> 6. You have a significant lack of data regarding embedded systems, which
> >> is one of the two biggest segments of Linux's market share. You list no
> >> results for any pre-ARMv6 systems (Linux still runs on and is regularly
> >> used on ARMv4 CPU's, and it's worth also pointing out that the values on
> >> the ARMv6 systems are themselves below average), any MIPS systems other
> >> than 24k and 4k (which is not a good representation of modern embedded
> >> usage), any SPARC CPU's other than UltraSPARC (ideally you should have
> >> results on at least a couple of LEON systems as well), no tight-embedded
> >> PPC chips (PPC 440 processors are very widely used, as are the 7xx and
> >> 970 families, and Freescale's e series), and only one set of results for
> >> a tight-embedded x86 CPU (the Via Nano, you should ideally also have
> >> results on things like an Intel Quark). Overall, your test system
> >> selection is not entirely representative of actual Linux usage (yeah,
> >> ther'es a lot of x86 servers out there running Linux, there's at least
> >> as many embedded systems running it too though, even without including
> >> Android).
> >
> > Perfectly valid argument. But I programmed that RNG as a hobby -- I do not
> > have the funds to buy all devices there are.
>
> I'm not complaining as much about the lack of data for such devices as I
> am about you stating that it will work fine for such devices when you
> have so little data to support those claims. Many of the devices you
Little data, interesting statement for results on 200+ systems including all
major CPU arches all showing information leading in the same directions.
> have listed that can be reasonably assumed to be embedded systems are
> relatively modern ones that most people would think of (smart-phones and
> similar). Such systems have almost as much if not more interrupts as
> many desktop and server systems, so the entropy values there actually do
Please re-read the documentation: the testing and the test analysis remove
outliers from interrupts and such to get a worst-case testing.
> make some sense. Not everything has this luxury. Think for example of
> a router. All it will generally have interrupts from is the timer
> interrupt (which should functionally have near zero entropy because it's
> monotonic most of the time) and the networking hardware, and quite
> often, many of the good routers operate their NIC's in polling mode,
> which means very few interrupts (which indirectly is part of the issue
> with some server systems too), and therefore will have little to no
> entropy there either. This is an issue with the current system too, but
> you have almost zero data on such systems systems yourself, so you can't
> argue that it makes things better for them.
It would be good to read the documentation in full -- the RNG does not rest on
interrupts.
Ciao
Stephan
next prev parent reply other threads:[~2016-06-21 18:04 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 18:37 [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller
2016-05-31 18:37 ` [PATCH v4 1/5] crypto: DRBG - externalize DRBG functions for LRNG Stephan Mueller
2016-05-31 18:38 ` [PATCH v4 2/5] random: conditionally compile code depending on LRNG Stephan Mueller
2016-05-31 18:39 ` [PATCH v4 3/5] crypto: Linux Random Number Generator Stephan Mueller
2016-05-31 18:39 ` [PATCH v4 4/5] crypto: LRNG - enable compile Stephan Mueller
2016-05-31 18:39 ` [PATCH v4 5/5] random: add interrupt callback to VMBus IRQ handler Stephan Mueller
2016-05-31 22:34 ` [PATCH v4 0/5] /dev/random - a new approach George Spelvin
2016-06-15 16:17 ` David Jaša
2016-06-15 16:58 ` Stephan Mueller
2016-06-17 13:56 ` David Jaša
2016-06-17 15:26 ` Sandy Harris
2016-06-18 8:22 ` Stephan Mueller
2016-06-18 8:21 ` Stephan Mueller
2016-06-18 14:44 ` Theodore Ts'o
2016-06-18 16:31 ` Stephan Mueller
2016-06-20 17:07 ` Austin S. Hemmelgarn
2016-06-20 18:32 ` Stephan Mueller
2016-06-21 13:05 ` Austin S. Hemmelgarn
2016-06-21 13:19 ` Tomas Mraz
2016-06-21 17:18 ` Austin S. Hemmelgarn
2016-06-21 17:23 ` Stephan Mueller
2016-06-21 17:54 ` Austin S. Hemmelgarn
2016-06-21 18:05 ` Stephan Mueller
2016-06-21 13:20 ` Stephan Mueller
2016-06-21 17:51 ` Austin S. Hemmelgarn
2016-06-21 18:04 ` Stephan Mueller [this message]
2016-06-21 19:31 ` Austin S. Hemmelgarn
2016-06-22 5:16 ` Stephan Mueller
2016-06-22 12:54 ` Austin S. Hemmelgarn
2016-06-22 13:25 ` Stephan Mueller
2016-06-21 13:42 ` Pavel Machek
2016-06-21 17:17 ` Austin S. Hemmelgarn
2016-06-21 12:25 ` David Jaša
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=1900555.p3fYFz9p7D@positron.chronox.de \
--to=smueller@chronox.de \
--cc=ahferroin7@gmail.com \
--cc=andi@firstfloor.org \
--cc=cryptography@lakedaemon.net \
--cc=djasa@redhat.com \
--cc=hpa@linux.intel.com \
--cc=joe@perches.com \
--cc=jsd@av8n.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=pavel@ucw.cz \
--cc=sandyinchina@gmail.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 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).