On Tue, 2021-11-30 at 15:04 +0100, Greg Kroah-Hartman wrote:

On Tue, Nov 30, 2021 at 07:24:15AM -0500, Jeffrey Walton wrote:

quoted

On Mon, Nov 29, 2021 at 6:07 PM Greg Kroah-Hartman
[off-list ref] wrote:

quoted

...
Sometimes, yes, it is valid to have different implementations for things
that do different things in the same area (like filesystems), but for a
core function of the kernel, so far the existing random maintainer has
not wanted to have multiple implementations.  Same goes for other parts
of the kernel, it's not specific only to this one very tiny driver.

As a counterpoint, we do not allow duplicate drivers that control the
same hardware types in the tree.  We have tried that in the past and it
was a nightmare to support and maintain and just caused massive user
confusion as well.  One can argue that the random driver is in this same
category.

I think an argument could be made that they are different drivers
since they have different requirements and security goals. I don't
think it matters where the requirements came from, whether it was ad
hoc from the developer, NIST, KISA, CRYPTREC, NESSIE, or another
organization.

Maybe the problem is with the name of the driver? Perhaps the current
driver should be named random-linux, Stephan's driver should be named
random-nist, and the driver should be wired up based on a user's
selection. That should sidestep the problems associated with the
"duplicate drivers" policy.

The "problem" here is that the drivers/char/random.c file has three users,
the userspace /dev/random and syscall api, the in-kernel "here's some
entropy for the random core to use" api, and the in-kernel "give me some
random data" api.

Odds are, you REALLY do not want the in-kernel calls to be pulling from
the "random-government-crippled-specification" implementation, right?

You really *do* want that.
When our customers are mandated to use FIPS certified cryptography,
they want to use it for kernel cryptography as well, and in general
they want to use a certified randomness source as well.

I do not get why you call the implementation crippled? The
specification is quite thorough and provides well reasoned requirements
as well as self-test that insure coding mistakes won't end up returning
non-random values.

I understand the mistrust vs gov agencies due to past mishaps like the
Dual-DRBG thing, but we are not talking about something like that in
this case. NIST is not mandating any specific algorithmic
implementation, the requirement set forth allow to use a variety of
different algorithms so that everyone can choose what they think is
sane.

Again, just try evolving the existing code to meet the needs that you
all have, stop trying to do wholesale reimplementations.  Those never
succeed, and it's pretty obvious that no one wants a "plugin a random
random driver" interface, right?

I think one of the issues is that the number of changes required
against the current random driver amount essentially to a re-
implementation. Sure, you can do it as a series of patches that
transform the current code in something completely different.

And the main question here is, how can we get there, in any case, if
the maintainer of the random device doesn't even participate in
discussions, does not pick obvious bug fixes and is simply not engaging
at all?

Your plan requires an active maintainer that guides these changes and
interact with the people proposing them to negotiate the best outcome.
But that is not happening so that road seem blocked at the moment.

HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc