Re: [PATCH v24 01/12] Linux Random Number Generator

Stephan Müller [off-list ref] 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.