[Bug 230875] Revisit decision to not block read_random(9) on being seeded

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230875

            Bug ID: 230875
           Summary: Revisit decision to not block read_random(9) on being
                    seeded
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: cem at freebsd.org

read_random() is used, mostly without error checking, in a lot of very
sensitive places in the kernel — including seeding the even more widely used
arc4random(9).

I don't think this is a sane default.  I am not really convinced it makes sense
for any use, but at least most uses should block until the system RNG is
seeded.  Currently none do, and very few check that any random data was
actually returned.  That is a problem.

We should change read_random's return type to 'void' to match most use, and
have it block until the RNG is seeded.  This is the most expedient way to make
the behavior match the name.

Optionally, if it is really needed, add a second API,
read_random_dangerous_I_know_what_I_am_doing() that allows non-blocking reads,
*and tag the return value __result_use_check*.  For those few consumers that
truly need nonblocking access to RNG during early boot, *and are prepared to
deal with not having random data available*, update to use this dangerous API.

The tradeoffs here are:

Pro:

1. (Especially if the 2nd API is not added,) we have rigorous assurance that no
sensitive keying information generated by these APIs is highly predictable.

Cons:

1. May block availability of some subsystems if the system does not have
boot-time entropy.

Counter arguments: I think this is solved in two parts: one, per the current
comment in chacha20_randomstir: "The answer is to make sure there is an entropy
stash at shutdown time."  But that is a bit glib and assumes nothing goes wrong
with the filesystem, for example.

The second prong is that core system services need to be able to start without
RNG available, and initialize keys later when the RNG is available.  We should
at least be able to proceed to userspace init + rc with a blocked RNG.  This
should be easy to test with a tunable + sysctl.

-- 
You are receiving this mail because:
You are the assignee for the bug.