Date: Sat, 25 Aug 2018 00:47:18 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230875] Revisit decision to not block read_random(9) on being seeded Message-ID: <bug-230875-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230875 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@FreeBSD.org Reporter: cem@freebsd.org read_random() is used, mostly without error checking, in a lot of very sensitive places in the kernel =E2=80=94 including seeding the even more wi= dely used arc4random(9). I don't think this is a sane default. I am not really convinced it makes s= ense 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 m= ake 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 rea= ds, *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 A= PI. The tradeoffs here are: Pro: 1. (Especially if the 2nd API is not added,) we have rigorous assurance tha= t 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 ent= ropy stash at shutdown time." But that is a bit glib and assumes nothing goes w= rong with the filesystem, for example. The second prong is that core system services need to be able to start with= out RNG available, and initialize keys later when the RNG is available. We sho= uld at least be able to proceed to userspace init + rc with a blocked RNG. This should be easy to test with a tunable + sysctl. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230875-227>