On Mon, Jan 10, 2022 at 4:08 PM Marcelo Henrique Cerri <marcelo.cerri@xxxxxxxxxxxxx> wrote: > > Just to confirm, this little patch here gives you FIPS certification? > It does On Mon, Jan 10, 2022 at 7:29 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > Now, the idea of certifying the whole kernel as a FIPS cryptographic module is > stupid Alright, so if that's the case, then what you ostensibly want is: a) Some cryptoapi users to use crypto_rng_get_bytes, as they already do now. (In a private thread with Simo, I pointed out a missing place and encouraged him to send a patch for that but none has arrived.) b) Userspace to use some other RNG. (a) is basically already done. (b) can be accomplished in userspace by just (i) disabling getrandom() (making it return ENOSYS), and then (ii) replacing the /dev/urandom path with a CUSE device or similar. I suppose (b.i) might be able to be done with some bpf seccomp cgroup situation. Or, if that's problematic, somebody could propose a "disable getrandom(2)" cmdline option. That doesn't seem very hard. And (b.ii) could use combined inputs from /dev/urandom and whatever FIPSy userspace jitter entropy daemon you have. In order to prevent the actual security from regressing on this, all you have to do is ensure that you're always using at least 32 bytes from the kernel's real /dev/urandom, and then whatever you add on top of that becomes just for the certification aspect. As your various green compliance checkboxes change over time and per region, you can just swap out the extra-paper-pushing-bytes-on-top with whatever the particular requirements of a certification body are. And you get to do this all in userspace. Marcelo/Simo - could you tell me what you find deficient about that plan? It strikes me that this would give you maximum flexibility and pretty much accomplish the goals? Thanks, Jason
