Re: [PATCH v43 01/15] Linux Random Number Generator

[Jason A. Donenfeld]

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