Re: [PATCH v2 02/03]: hwrng: create filler thread
From: Andy Lutomirski
Date: Thu Mar 27 2014 - 11:47:54 EST
On Thu, Mar 27, 2014 at 7:54 AM, Torsten Duwe <duwe@xxxxxx> 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@xxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/