Messages in this thread | | | From | Andy Lutomirski <> | Date | Thu, 27 Mar 2014 08:47:24 -0700 | Subject | Re: [PATCH v2 02/03]: hwrng: create filler thread |
| |
On Thu, Mar 27, 2014 at 7:54 AM, Torsten Duwe <duwe@lst.de> wrote: > On Wed, Mar 26, 2014 at 06:03:37PM -0700, H. Peter Anvin wrote: >> I'm wondering more about the default. We default to 50% for arch_get_random_seed, and this is supposed to be the default for in effect unverified hwrngs... > > If the default were 0, it would be exactly the old behaviour. > How about that? Plus, driver authors would have to come up > with an estimate on their own. > >> On March 26, 2014 5:50:09 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote: >> >> + "current hwrng entropy estimation per mill"); >> > >> >As an electrical engineer (sort of), I can't read this without thinking >> >you're talking about the amount by which the current is derated. For >> >example, a 14-50 electrical outlet is rated to 50 Amps. If you use it >> >continuously for a long time, though, the current is derated to 40 >> >Amps. >> > >> >Shouldn't this be called credit_derating or, even better, >> >credit_per_1000bits? > > That's an awkward name for a parameter.
I don't think it's worse than credit_derating.
> >> >Also, "per mill" is just obscure enough that someone might think it >> >means "per million". > > No. I looked it up, as we have the precise term "Promille" in German. > Also in electrical engineering, (imperial :-) PCB design, a mil > is one 1000th of an inch. Per million would surely be named PPM. >
I'm not saying that "per mill" is wrong -- I'm just saying it's obscure and may confuse people.
>> >Why the check for derating > 0? Paranoid users may want zero credit, >> >but they probably still want the thing to run. > > [...] > >> >ratelimit (heavily), please. > > The kthread will stop once the estimated entropy is above the threshold. > derating=0 will wind up one CPU core to 100%. So it's an elegant way > to disable the whole mechanism. >
Sorry, I didn't mean ratelimit the loop. I meant ratelimit the printk.
>> >Also, would it make sense to round-robin all hwrngs? Even better: >> >collect entropy from each one and add them to the pool all at once. If >> >so, would it make sense for the derating to be a per-rng parameter. > > Finally, the derating _is_ a per-RNG parameter. I also thought about > mixing already, but first I want to see a machine with more than 1 HWRNG :-) >
Any Haswell machine with another hwrng will have two of them. (I'm not sure that the rdrand/rdseed thing registers as an hwrng, but still...)
--Andy
| |