Eric Biggers <ebiggers@xxxxxxxxxx> writes: > On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote: >> >> Would some maintainer please comment on potential problems or >> shortcomings? >> > > Well, very people are experts in the Linux RNG *and* have time to review large > patchsets, especially when three people are all proposing conflicting changes. > And those that might be able to review these patches aren't necessarily > interested in compliance with particular government standards. To make it clear: I'm personally not really enthusiastic about some of the restrictions imposed by SP800-90 either and Jason certainly has a point with his concerns about "subpar crypto" ([1]). However, at the same time I'm acknowledging that for some users FIPS compliance is simply a necessity and I don't see a strong reason why that shouldn't be supported, if doable without negatively affecting !fips_enabled users. > Note that having multiple RNG implementations would cause fragmentation, more > maintenance burden, etc. So IMO, that should be a last resort. Instead we > should try to find an implementation that works for everyone. I.e., at least to > me, Nicolai's patchset seems more on the right track than Stephan's patchset... I suppose that this concern about fragmentation is among the main reasons for reservations against Stephan's LRNG patchset and that's why I posted this RFC series here for comparison purposes. But note that, as said ([2]), it's incomplete and the only intent was to provide at least a rough idea on what it would take to move the current /dev/random implementation towards SP800-90 -- I was hoping for either a hard NACK or something along the lines of "maybe, go ahead and let's see". > However, not everyone cares about "compliance". So any changes for "compliance" > either need to have a real technical argument for making the change, *or* need > to be optional (e.g. controlled by fips_enabled). Fully agreed. > AFAICS, this patchset mostly just talks about NIST SP800-90B compliance, and > doesn't make clear whether the changes make the RNG better, worse, or the same > from an actual technical perspective. > > If that was properly explained, and if the answer was "better" or at least > "not worse", I expect that people would be more interested. The goal was not to negatively affect !fips_enabled users, but as outlined in the cover letter ([2]), a performance impact had been measured on ARMv7. This probably isn't something which couldn't get sorted out, but I see no point in doing it at this stage, because - there's still quite some stuff missing for full SP800-90 compliance anyway, c.f. the overview at the end of [2] and - such optimizations would have bloated this patchset even more, e.g. for making fips_enabled a static_key, which should certainly go into a separate series. User visible effects set aside, an obvious downside of SP800-90 compliance would be the increase in code size and the associated maintenance burden. That being said, I can imagine that those boot health tests could also get enabled for !fips_enabled users in the future, if wanted: rather than inhibiting /dev/random output on failure, a warning would get logged instead. Whether or not this would be seen as an improvement is for others to judge though. Thanks, Nicolai [1] https://lkml.kernel.org/r/CAHmME9rMXORFXtwDAc8yxj+h9gytJj6DpvCxA-JMAAgyOP+5Yw@xxxxxxxxxxxxxx [2] https://lkml.kernel.org/r/20200921075857.4424-1-nstange@xxxxxxx -- SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg), GF: Felix Imendörffer
