On Mon, Nov 22, 2021 at 04:56:24PM +0000, John Haxby wrote:
>
>
> > On 22 Nov 2021, at 06:02, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Nov 22, 2021 at 06:34:43AM +0100, Stephan Mueller wrote:
> >> Am Sonntag, 21. November 2021, 23:42:33 CET schrieb Jason A. Donenfeld:
> >>
> >> Hi Jason,
> >>
> >>> 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?
> >
>
> We (Oracle) are carrying such a patch at the moment. We want this
> patch to be a temporary workaround simply to get FIPS certification in
> the current kernel.
>
> We're carrying this patch simply because the certification
> requirements changed and this was the quickest and easiest way to
> workaround today's problem. It won't fix tomorrow's problem and next
> time we, and others, attempt FIPS certification then we, and others,
> will need a different /dev/random because neither the old one nor our
> quick and dirty workaround will actually be acceptable.
>
> The commit we're carrying at the moment is here:
> https://github.com/oracle/linux-uek/commit/5ebe83413c7573d566e581461bc95f9f139c5d4d
> -- you'll notice that we have a different RNG in fips mode compared to
> normal mode.
Now that's a much smaller and simpler and easier to understand change,
compared to "rewrite the whole random number generator".
Why not work to get FIPS support merged properly upstream? I know there
are many people working to get FIPS certification, and while the
requirements seem to constantly change and are vague and random, it
would be great to stop duplicating all of this effort all the time.
> We really don't want to have to work out a new hack for future FIPS
> certifications and I'm sure no other distros want to do that either.
Great, why not work to solve this within what we have?
Remember, wholesale replacement is NOT how kernel development happens.
It's incremental evolution based on external need. It's not a "kill the
existing code and replace it from scratch" process.
> Personally, I'd far rather have any fips-certifiable /dev/random
> drivers be in mainline where everyone gets the same thing. I don't
> like carrying out-of-tree patches like this, it's not healthy.
Great, please work to make this happen within what we have today.
But adding a stand-alone separate random subsystem just for this is not
a good idea and is one huge reason why this patch set keeps being
ignored by the kernel developers.
thanks,
greg k-h
