Re: [PATCH 4/5] tsc: wire up entropy generation function

[Jarod Wilson <jarod@redhat.com>]

H. Peter Anvin wrote:
> On 06/13/2011 05:39 PM, Kent Borg wrote:
>> I was assuming that drivers, responding to an interrupt from some
>> external event, would want to make this call.
>> Such as a network driver.
>
> Those already are doing this.
>
>> Two points:
>>
>> 1. Why look at the high-order bits?  How are they going to have values
>> that cannot be inferred?  If you are looking for entropy, the low-order
>> bits is where they're going keep it.  (Think Willie Sutton.)  If looking
>> at the low-byte is cheaper, then let's be cheap.  If, however, if
>> looking at more bytes *is* as cheap, then there is no harm.  But in any
>> case let's keep the code lean enough that it can be called from an
>> interrupt service routine.
>
> Consider the case where the TSC is running in steps of 64 and you're
> using the low 6 bits.

What if we mix the low byte into the pool, but only increase the entropy 
estimate if a comparison with the prior read actually shows a change?

Another thought is to perhaps mix the counter value with a value read 
from ansi_cprng, which is similar to a tactic referred to in NIST's 
140sp750.pdf.

Peter, as long as I've got your attention here... Patch 3 in the set 
adds essentially the same sort of support using the hpet instead of the 
tsc. Is that less contentious, as far as precision in the low byte(s) to 
provide entropy data?

My initial local implementation was actually hpet-only, before reworking 
things to try to be more generic.

-- 
Jarod Wilson
jarod@redhat.com