Strong agree on separating any whitespace commits from functional commits. This is especially important for security sensitive content.

Forgot to add this to the commit message to auto-close. This was committed as r52684.

Based on conversation with brooks, this doesn't need an advisory. Local DoS are exempt from SAs and the information leak is very low quality.

I don't know enough to review this request. Maybe delphij, emaste or one of the other secteam members has more domain experience here.

Approved based on timeout from delphij.

I have no objection. I'm not sure I'm qualified to weigh in on it. If markm is okay with it, then I would go ahead with it.

Logic looks reasonable to me. I have only read through the logic, not tested it myself.

@markm Can you please specifically address the comment @jmg posted on this review (and it's ancestor)?

Add secteam instead of just me.

Address feedback from bjk.

Adding cperciva and jmg who may be able to help provide some opinions about how they think this should go.

Okay, based on that, looks good to me.

Would it be better off to just not do checksumming for this and use the source as is?

In D13925#292062, @cem wrote:

In D13925#292058, @badfilemagic_gmail.com wrote:

Conrad, thanks for the details. I also looked at the code in the other review and it looks good. I’d expect whitened output from the ctr-aes drbg to measure ~6.5 bits when put through the sp800-90b tool. That’s roughly what you get out of 1000000 samples from RDRND on Intel.

FWIW, these processors also have RDRAND. I don't know if the RDRAND implementation is related to the CCP device TRNG or not.

I obtained some sample output from the CTR-AES DRBG via kgdb and /dev/mem:

This is fine (obviously missing the actual implementation). Adding Dean to the reviewers, he has history in doing assessments of HW TRNG and might be a good collaborator to look at the quality of the bits coming from ccp(4).