On Tue, Nov 30, 2021 at 10:13:26AM -0500, Jeffrey Walton wrote: > On Tue, Nov 30, 2021 at 9:04 AM Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Nov 30, 2021 at 07:24:15AM -0500, Jeffrey Walton wrote: > > > On Mon, Nov 29, 2021 at 6:07 PM Greg Kroah-Hartman > > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > ... > > > > 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? > > It's not a question of whether some folks want it or not. They have to > accept it due to policy. They have no choice in the matter. I strongly doubt that policy dictates all of the current calls to get_random_*() require that they return data that is dictated by that policy. If so, that's not a valid specification for a variety of reasons (i.e. it will break other specification requirements...) thanks, greg k-h
