[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACXcFmkBQAZd4bSfQvqeCsoTjMr0-uSjKciD6y9EkMN3c9ppJw@mail.gmail.com>
Date: Sun, 24 Nov 2019 12:51:19 +0800
From: Sandy Harris <sandyinchina@...il.com>
To: Stephan Müller <smueller@...onox.de>
Cc: Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, linux-api@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Alexander E. Patrakov" <patrakov@...il.com>,
"Ahmed S. Darwish" <darwish.07@...il.com>,
"Theodore Y. Ts'o" <tytso@....edu>, Willy Tarreau <w@....eu>,
Matthew Garrett <mjg59@...f.ucam.org>,
Vito Caputo <vcaputo@...garu.com>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
William Jon McCann <mccann@....edu>,
zhangjs <zachary@...shancloud.com>,
Andy Lutomirski <luto@...nel.org>,
Florian Weimer <fweimer@...hat.com>,
Lennart Poettering <mzxreary@...inter.de>,
Nicolai Stange <nstange@...e.de>,
"Peter, Matthias" <matthias.peter@....bund.de>,
Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
Roman Drahtmueller <draht@...altsekun.de>,
Neil Horman <nhorman@...hat.com>
Subject: Re: [PATCH v24 01/12] Linux Random Number Generator
Stephan Müller <smueller@...onox.de> wrote:
> In an effort to provide a flexible implementation for a random number
> generator that also ...
As usual, some of your proposals make considerable sense to me &
others do not, at least on first reading. I may have more comments
after reflecting some.
Meanwhile, a couple of things jump out at me:
> (a) When an interrupt occurs, the high-resolution time stamp is mixed
> into the LFSR. ...
>
> (b) HID event data like the key stroke or the mouse coordinates are
> mixed into the LFSR. ...
>
> (c) Device drivers may provide data that is mixed into the LFSR. ...
Why into the LFSR instead of into the entropy pool?
> The LRNG allows the TRNG and secondary DRNG mechanism to be changed
> at runtime.
Why? This strikes me as pointless complication.
> * high performance of interrupt handling code: The LRNG impact on the
> interrupt handling has been reduced to a minimum. On one example
> system, the LRNG interrupt handling code executes within an average
> of 65 cycles whereas the existing /dev/random on the same device
> takes about 97 cycles when measuring the execution time of
> add_interrupt_randomness().
Assuming you do this without sacrificing the input mixing, this
would be worth submitting as a separate patch. Saving cycles
on every interrupt definitely looks worth doing.
> * lockless LFSR to collect raw entropy
This too.
Powered by blists - more mailing lists