linux-kernel - Huge amount of randomness with cuse and "urandompar"

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>] [day] [month] [year] [list]

Date:	Fri, 14 Oct 2011 22:38:07 +0200
From:	Michael Büsch <m@...s.ch>
To:	lkml <linux-kernel@...r.kernel.org>
Subject: Huge amount of randomness with cuse and "urandompar"

Hi there,

from time to time I need huge amounts of reasonably strong random
data. I want to use /dev/urandom for this, as it seems to have received
enough testing and has various good sources of entropy and good
support by tools such as rngd.

However, /dev/urandom does not seem to benefit at all from multicore systems.
Large parts of the urandom read-codepath in the kernel seem to be completely
lockless, though. So my basic idea was to throw a lot of reader threads at it
while preserving the convenient character device interface. Which lead
to this proof-of-concept CUSE project:

http://bues.ch/gitweb?p=urandompar.git;a=summary
git://git.bues.ch/urandompar.git

So from a first look it doesn't seem too bad, performance wise.
It seems that it currently scales well enough up to 4 CPUs.
Here's a simple chart of a trivial benchmark on a 6-core CPU:
http://bues.ch/misc/urandomparscale.pdf

I didn't profile it with oprofile, yet, but my guess is that it
runs more and more into entropy_store spinlock contention with >4 CPUs.
This has to be verified, though.

An open question still is: What are the implications on the data quality?
Does this massive parallelism affect the urandom algorithms in any way?

Can the bottleneck, that prevents it from scaling properly, be fixed?

Searching for testers, comments and answers. :)

-- 
Greetings, Michael.
--
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/