LGTM.

Against my better judgement, I kept the !DEV_RANDOM case as some folks insisted on being able to use preferred tools (ssh) even on insecure embedded hardware. I'm happy to se you fix it, if it means I don't get the flak ]:->

I'm happy with this, in principle. I defer on the kernel innards, but the general engineering looks sound.

Accept with delphi's changes.

OK. I like these diffs even better.

You need the security officer's say-so. I have a personal wavier when I do such commits myself (as I wrote the main random device), but this is non-transferrable, as far as I know.

LGTM.

Very good!

Nice work! Out for interest, why make the output generator selectable? Why not switch completely to Chacha20?

Overcome By Events.

I like this!

OK.

Looks good to me.

If it doesn't crash anything, then fine! I had stack problems at some point.

Commit r338324 closes this.

Sigh. I think I have all cem@'s review comments done now.

Rebase to top of HEAD.

Address cmem@'s review comments.

Adress some review concerns from cem@, and a few of my own while I'm here.

Fix documentation nit.

Add the "differential update" URI to the commit message.
Correct sys/conf/NOTES comment.

In D16873#359829, @jmg wrote:

@delphij this is my comment copied over from https://reviews.freebsd.org/D16866?id=47165 that was unaddressed.

Thanks folks! Tinderbox build going, then I'll commit.

Thanks folks! Tinderbox build going, then I'll commit.

Address review commnts from delphij.

Apologies to delphij for abandoning the previous identical-looking commit. I was making a pig's ear of the archanist work.

This improves things drastically from what they were. More detailed work will follow.

Split into two separate commits as per review request.

Add the differential revision to the commit message.

There were a couple of changes which are largely cosmetic to do with #if logic. Change if you want, otherwise LGTM.

My "LGTM" assumes requested changes are taken.

LGTM

Looks good to me!

I'm happy with this.

(from hospital bed)

(From hospital bed)

I will be able to help in a week or two when I get out of hospital - I'm about to have an operation.

That might be an idea. The actual PPS rate could be unable, as optimal choices may not be universal. I'm leery of turning off harvesting altogether as that would be a big POLA violation, but lessening the impact makes sense.

Do you mean not harvesting the packet contents?

I'm having a bit of a problem parsing this; could I please ask you to rephrase?

I see an opportunity for documentation improvement here. :-)

Does Kerberised telnet still work after this? ISTR (many years ago) that a successful compile does not necessarily mean a working binary due to similarly named libraries.

In D10048#215609, @des wrote:

Please allow me some time to commit my Chacha20 implementation first so we can use that instead of the legally dubious version which is included in this patch. I hit a snag that I haven't had time to debug, but I'm hoping to have it done by Tuesday.

Address reviewer comments.

In D10048#209666, @rwatson wrote:

In D10048#209661, @markm wrote:

RWatson: Not to get picky or anything, but there was already a malloc() in that place.

I've misread the patch; I'm happy for this to be fixed in a separate commit. I'll continue to sort out a DPCPU man page, however.

In D10048#209666, @rwatson wrote:

In D10048#209661, @markm wrote:

RWatson: Not to get picky or anything, but there was already a malloc() in that place.

I've misread the patch; I'm happy for this to be fixed in a separate commit. I'll continue to sort out a DPCPU man page, however.

RWatson: Not to get picky or anything, but there was already a malloc() in that place.

In D10048#209647, @rwatson wrote:

Your commit introduces per-CPU memory allocation.

In D10048#209623, @rwatson wrote:

In D10048#209275, @markm wrote:

• I feel that using sleepable mutexes here is fine -- the difference in performance is negligible on most contemporary microarchitectures, and there is an argument for moving some of our other critical sections to being mutexes (e.g., per-CPU UMA caches).

I'm concerned about cpu migration. Mutexes don't guarantee that a thread will stay on the same cpu, right?

This is correct: you must make sure that you continue to access state on the CPU for which you acquired a mutex -- e.g., by caching a pointer to the per-CPU state you are accessing, in case migration takes place.

In D10048#209125, @rwatson wrote:

Just a few quick comments:

• I find it confusing that the new code is in a file named arc4random.c.

I'm not comfortable with critical sections for now. Back to mutexes
as before. I'm happy to revisit this later.

Address review comments.

Respond to reviewer.

Address review comments.

Reply to reviewer.

Reply to reviewers.