Re: [PATCH v43 01/15] Linux Random Number Generator

On Mon, Nov 22, 2021 at 10:09:05AM -0500, Simo Sorce wrote:

On Mon, 2021-11-22 at 07:55 +0100, Greg Kroah-Hartman wrote:

quoted

On Mon, Nov 22, 2021 at 07:42:02AM +0100, Stephan Mueller wrote:

quoted

Am Montag, 22. November 2021, 07:02:14 CET schrieb Greg Kroah-Hartman:

Hi Greg,

quoted

On Mon, Nov 22, 2021 at 06:34:43AM +0100, Stephan Mueller wrote:

quoted

Am Sonntag, 21. November 2021, 23:42:33 CET schrieb Jason A. Donenfeld:

Hi Jason,

quoted

Hi Stephan,

You've posted it again, and yet I still believe this is not the
correct design or direction. I do not think the explicit goal of
extended configurability ("flexibility") or the explicit goal of being
FIPS compatible represent good directions, and I think this introduces
new problems rather than solving any existing ones.

The members from the Linux distributions that are on copy on this may tell
you a different story. They all developed their own downstream patches to
somehow add the flexibility that is needed for them. So, we have a great
deal of fragmentation at the resting-foundation of Linux cryptography.

What distros specifically have patches in their kernels that do
different things to the random code path?  Do you have pointers to those
patches anywhere?  Why have the distros not submitted their changes
upstream?

I will leave the representatives from the distros to chime in and point to 
these patches.

Then why not work with the distros to get these changes merged into the
kernel tree?  They know that keeping things out-of-the-tree costs them
time and money, so why are they keeping them there?

I can speak for my distro.
We have not proposed them because they are hacks, we know they are
hacks, and we know they are not the long term solution.

Hacks that work today are the step toward a real solution.

So please, propose them and we can evolve from that.

Yet we have no better way (in our products, today) so far to deal with
these issues because what is needed is an effort like LRNG (does not
have to be this specific implementation), because hacks will not cut it
in the long term.

So you want to ship this separate driver instead?  Great, but as I said
elsewhere, doing a wholesale replacement is almost never the right thing
to do.

Work off of those known-working-and-certified hacks.  Submit them and
let's go from there please.

thanks,

greg k-h