linux-kernel - Re: [PATCH v2 02/03]: hwrng: create filler thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 27 Mar 2014 08:47:24 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Torsten Duwe <duwe@....de>
Cc:	"H. Peter Anvin" <hpa@...or.com>, "Theodore Ts'o" <tytso@....edu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Matt Mackall <mpm@...enic.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Arnd Bergmann <arnd@...db.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Satoru Takeuchi <satoru.takeuchi@...il.com>,
	ingo.tuchscherer@...ibm.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Hans-Georg Markgraf <MGRF@...ibm.com>,
	Gerald Schaefer <gerald.schaefer@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Joe Perches <joe@...ches.com>
Subject: Re: [PATCH v2 02/03]: hwrng: create filler thread

On Thu, Mar 27, 2014 at 7:54 AM, Torsten Duwe <duwe@....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@...capital.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/