linux-kernel - Re: [PATCH 1/3] Make /dev/urandom scalable

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]

Message-ID: <5603E083.8020004@gmail.com>
Date:	Thu, 24 Sep 2015 07:37:39 -0400
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	tytso@....edu, linux-kernel@...r.kernel.org,
	kirill.shutemov@...ux.intel.com, herbert@...dor.apana.org.au,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 1/3] Make /dev/urandom scalable

On 2015-09-23 19:28, Andi Kleen wrote:
>> I'd almost say that making the partitioning level configurable at
>> build time might be useful.  I can see possible value to being able
>> to at least partition down to physical cores (so, shared between
>> HyperThreads on Intel processors, and between Compute Module cores
>> on AMD processors), as that could potentially help people running
>> large numbers of simulations in parallel.
>
> I don't like build time size configurations. It doesn't make sense
> for simulations to use urandom. It may make sense to have
> some run time tunable, but for now that's too much complexity.
> So I'll stay with the simpler per node pool for now.
Using /dev/urandom directly, yes that doesn't make sense because it 
consistent returns non-uniformly random numbers when used to generate 
larger amounts of entropy than the blocking pool can source, but most 
that use their own PRNG's seed them off of /dev/urandom, and there are 
cases I've seen of people doing very large numbers (on the order of 
millions) of short (15 or so minutes run time on decent hardware) 
simulations that do this.

As for a run-time tunable, I agree that that would be better than 
build-time, and I also agree that it should be done later.  The only 
reason I suggested a build time tunable was that I figured it would be a 
lot easier to do than run-time.



Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)