Thread (99 messages) 99 messages, 19 authors, 2022-01-11

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

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2021-11-22 06:55:41
Also in: lkml

On Mon, Nov 22, 2021 at 07:42:02AM +0100, Stephan Mueller wrote:
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 recommend getting the distros to chime in on what their requirements
are for the random code would probably be best as they are the ones that
take on the "random fips requirement of the day" more than anyone else.
Yet, these changes are commonly a band-aid only that have some additional 
drawbacks. Bottom line, there is no appropriate way with the current code to 
allow vendors what they want to achieve. One hint to what changes vendors are 
attempting can be found in [1] slide 20.
What exactly do vendors "want to achieve"?  Where are they saying this?
[1] https://www.chronox.de/lrng/doc/lrng_presentation_v43.pdf
I see nothing on that slide that mentions actual requirements other than
"the current code does not match this random government regulation".

Please provide valid reasons, from distros.

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help