I think you might want to bump the date (currently read as "January 10, 1995") when committing but it looks otherwise fine to me.

Minor nit: could you please quote variables with {} (e.g. $VAR -> ${VAR})?

LGTM

LGTM.

LGTM, thanks!

Looks reasonable.

LGTM.

This is reasonable.

LGTM (but are we expecting COMPAT_FREEBSD11 defined in places where FreeBSD is not defined?)

Mostly LGTM.

This would increase stack usage for /dev/random read by 32 bytes, but I think it's small enough and make the code easier to reason for MP safety (the buffer is not meant to be shared by two different threads), so consider this a LGTM from secteam@ as long as there is no objection raised by September 1st.

Looks good to me. @jmg do you have any concerns if this is landed as-is?

LGTM from an earlier review.

It seems that the other read_random instances in network stack should do the same as well (probably beyond scope of this changeset though).

LGTM. cem@ or markm@, could you please commit this before code freeze?

LGTM.

LGTM as-is, but with some minor suggestions inline.

I think the direction is good and the changeset looks good to me in principal. Could you please make a change so it would print errline, which would make it easier for administrators to find out where the issue is?

Oops, omit change in stdlib.h.

Update comment, no functional change.

Addressed contrib/ntp/lib/isc/random.c issue; heimdal part would be left as-is for now (I think we can use HAVE_RAND but let's do it in a follow up commit).

Remove #else in contrib/ntp/lib/isc/random.c.

Remove manual page for arc4random_stir and arc4random_addrandom.

Drop chacha_private.h and address various reviewer comments.

Will commit the arc4random_uniform portion of change (which contained some trivial changes to type to make the code C99 compliant) to reduce the size of this changeset and revise to address some comments with plan outlined inline.

In D16706#355122, @cem wrote:

Hi,

Thanks for the quick feedback!

In D16706#355121, @delphij wrote:

for example the use of MAP_INHERIT_ZERO or FreeBSD's INHERIT_ZERO to detect fork

That would be an additional enhancement, no? I don't think this change introduces a regression there.

I think we should come up with a design first, it's important not to repeat other's errors. (I have a version based on earlier OpenBSD arc4random() [1] that was used in a disk wiper which still suffers from a few issues that OpenBSD have fixed in their later versions, for example the use of MAP_INHERIT_ZERO or FreeBSD's INHERIT_ZERO to detect fork.). My recommendation is to start over from a more recent OpenBSD version.

LGTM'ing so we don't become a blocker (the code construction is similar to ivy.c). Please go ahead with commit after 14th August if nobody raises problems that they thinks should block the commit.

LGTM, thanks!

LGTM. Thanks!

LGTM (please verify that rcorder /usr/local/etc/rc.d/* /etc/rc.d/* > /dev/null won't give cycles before committing).

In D16595#352569, @imp wrote:

Normally, these files aren't in the control of users...