On Mon, Jan 10, 2022 at 10:10:15PM -0500, Theodore Ts'o wrote: > Right now, the enterprise distros are doing their own thing, and quite > frankly, I don't see a problem with that. If it turns out DRBG is > less secure (and there are some things that fill me with disquiet), > then let them take the economic consequences, since they are the ones > who are doing this for the economic advantages of trying to claim FIPS > compliance. The goal is to identify a solution that avoids the enterprise kernels needing to do their own thing. They're in a position to globally LD_PRELOAD something to thunk getrandom() to improve compatibility if they want to, and they're also able to define the expected level of breakage if you enable FIPS mode. An approach that allows a single kernel to provide different policies in different contexts (eg, different namespaces could have different device nodes providing /dev/random) makes it easier to configure that based on customer requirements. > If we must support this in the upstream kernel, then configure it via > CONFIG_RANDOM_SECURITY_THEATRE which redirects getrandom(2) and > /dev/[u]random to DRBG. I'd prefer that it be possible for someone to > put "random_security_theatre=0" on the boot command line which would > disable redirecting the interfaces to DRBG so if it turns out that > DRBG *is* less secure, we can give advice on how to turn it off > without requiring a patched kernel. :-) The majority of enterprise customers don't need FIPS compliance, so all that would happen in that case is that the vendors would flip the sense of that config option and the docs for enterprise distros and mainline would be out of sync. I understand that this is a situation where a niche case is making life miserable for everyone else, and I understand that this is a hole that the enterprise world has dug for itself, but where there are people expressing a real tangible use case that exists for reasons outside their control, it really feels like we should try to find a solution that works for everyone.