Re: [PATCH 0/5] Feed entropy pool via high-resolution clocksources

[Jarod Wilson <jarod@redhat.com>]

john stultz wrote:
> On Mon, 2011-06-13 at 18:06 -0400, Jarod Wilson wrote:
>> Many server systems are seriously lacking in sources of entropy,
>> as we typically only feed the entropy pool by way of input layer
>> events, a few NIC driver interrupts and disk activity. A non-busy
>> server can easily become entropy-starved. We can mitigate this
>> somewhat by periodically mixing in entropy data based on the
>> delta between multiple high-resolution clocksource reads, per:
>>
>>    https://www.osadl.org/Analysis-of-inherent-randomness-of-the-L.rtlws11-developers-okech.0.html
>>
>> Additionally, NIST already approves of similar implementations, so
>> this should be usable in high-securtiy deployments requiring a
>> fair chunk of available entropy data for frequent use of /dev/random.
>>
>> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp750.pdf
>> (section 6.1 mentions a clock-based seed source).
>>
>> Yes, thus far, I've only bothered with x86-based clocksources, since that
>> is what I can test most easily. If this patch series isn't deemed totally
>> insane, adding support for other clocksources should be trivial.
>>
>> Also note that unless you explicitly build and load the clock-entropy
>> driver, there should be little or no change whatsoever to the way anything
>> behaves right now, its purely opt-in. There's probably room for some
>> improvement here, and I'm kind of outside my comfort area, but hey, it
>> seems to work pretty well here in my own testing, so here it is...
>>
>> Jarod Wilson (5):
>>    random: add new clocksource entropy interface
>>    clocksource: add support for entropy-generation function
>>    hpet: wire up entropy generation function
>>    tsc: wire up entropy generation function
>>    misc: add clocksource-based entropy generation driver
>
> So this is interesting work, but I have a few questions.
>
> 1) hpet_add_entropy() and tsc_add_entropy() are basically identical. It
> seems there should be a generic bit of code that uses the clocksource's
> read() function and does the same calculation.
>
> 2) If the .entropy() functions really aren't clocksource specific, it
> doesn't really seem like this functionality belongs in the clocksource
> layer. Instead it seems it should be a layer above, that makes use of
> the clocksource code in a generic fashion.

Wasn't sure at first if there might be a need for more differentiation 
in the entropy-gathering functions, but yeah, at least with these two, 
just using the clocksource read function from a common entropy-gathering 
function does look to make more sense.


> 3) Why are you making use of the curr_clocksource? The timekeeping code
> has very strict rules about what makes a clocksource usable for
> timekeeping. I suspect entropy generation has different requirements,
> and thus shouldn't lean on the curr_clocksource value (ie: TSC may be
> unsynced or halts in idle, and thus unusable for time, but likely still
> ok for entropy).
>
> 4) Further on that point, there's a likely bug: If an entropy supporting
> clocksource is available,  clocksource_entropy_available() will return
> true, but if the one curr_clocksource is not the one that supports
> entropy, clocksource_add_entropy() won't do anything. I suspect the
> add_entropy function needs to scan for a entropy flagged clocksource and
> use it instead.

Yeah, there are definitely different requirements. Using 
curr_clocksource was sort of the easy way out, I guess. :) So yeah, its 
entirely possible for someone to set a non-entropy-generating 
clocksource as their active one, and still have an entropy-generating 
one that is available -- I was actually running tsc as my primary 
clocksource and using the hpet for entropy in my initial internal 
implementation here.

Each clocksource currently has a rating for how good a timekeeping 
clocksource it is, would it make sense to have a second rating that 
indicates how good an entropy source it is, and use that to determine 
which clocksource would best serve for entropy generation?


> 5) Does the entropy calculation need to be flagged clocksource by
> clocksource? Or could a generic metric be made (ie: frequency?) in order
> to enable such functionality on all capable clocksources automatically?

I honestly haven't a clue here. I'm not sure if there are possibly 
clocksources that have a relatively high frequency, but lack precision 
in their lowest bits, nor am I sure (yet?) how to figure out what the 
frequency and/or precision of a given clocksource actually is. I guess I 
assume its non-trivial, since we have to have the 'rating' value to 
choose primary timekeeping clocksource.

My initial thinking is that it would be best to have this purely opt-in, 
for clocksources that have been evaluated and deemed acceptable for this 
use.

So I'll see what I can come up with in the way of removing the 
per-clocksource entropy functions. Doing so adds a new complication, by 
way of removing what I was keying off of to decide if the clocksource 
should be providing entropy, but perhaps I can try working in an entropy 
quality rating at the same time.

-- 
Jarod Wilson
jarod@redhat.com