linux-kernel - Re: [PATCH v4 0/5] /dev/random

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: <1883152.WnWCHsqf2W@positron.chronox.de>
Date:	Sat, 18 Jun 2016 10:21:16 +0200
From:	Stephan Mueller <smueller@...onox.de>
To:	David Jaša <djasa@...hat.com>
Cc:	Andi Kleen <andi@...stfloor.org>, sandyinchina@...il.com,
	Jason Cooper <cryptography@...edaemon.net>,
	John Denker <jsd@...n.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Joe Perches <joe@...ches.com>, Pavel Machek <pavel@....cz>,
	George Spelvin <linux@...izon.com>,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/5] /dev/random - a new approach

Am Freitag, 17. Juni 2016, 15:56:13 schrieb David Jaša:

Hi David,

> Hi Stephan,
> 
> thank you for your thorough reply,
> 
> On St, 2016-06-15 at 18:58 +0200, Stephan Mueller wrote:
> > Am Mittwoch, 15. Juni 2016, 18:17:43 schrieb David Jaša:
> > 
> > Hi David,
> > 
> > > Hello Stephan,
> > > 
> > > Did you consider blocking urandom output or returning error until
> > > initialized? Given the speed of initialization you report, it shouldn't
> > > break any userspace apps while making sure that nobody uses predictable
> > > pseudoranom numbers.
> > 
> > My LRNG will definitely touch the beginning of the initramfs booting until
> > it is fully seeded. As these days the initramfs is driven by systemd
> > which always pulls from /dev/urandom, we cannot block as this would block
> > systemd. In Ted's last patch, he mentioned that he tried to make
> > /dev/urandom block which caused user space pain.
> 
> I was thinking along the lines that "almost every important package
> supports FreeBSD as well where they have to handle the condition so
> option to switch to Rather Break Than Generate Weak Keys would be nice"
> - but I didn't expect that systemd could be a roadblock here. :-/
> 
> I was also thinking of little devices where OpenWRT or proprietary
> Linux-based systems run that ended up with predictable keys way too
> ofter (or as in OpenWRT's case, with cumbersome tutorials how to
> generate keys elsewhere).

I have some ideas on how to handle that issue -- let me run some tests and I 
will report back.
> 
> > But if you use the getrandom system call, it works like /dev/urandom but
> > blocks until the DRBG behind /dev/urandom is fully initialized.
> > 
> > > I was considering asking for patch (or even trying to write it myself)
> > > to make current urandom block/fail when not initialized but that would
> > > surely have to be off by default over "never break userspace" rule (even
> > > if it means way too easy security problem with both random and urandom).
> > > Properties of your urandom implementation makes this point moot and it
> > > could make the random/urandom wars over.
> > 
> > That patch unfortunately will not work. But if you are interested in that
> > blocking /dev/urandom behavior for your application, use getrandom.
> 
> I'm QA with a touch of sysadmin so the numbers of apps to fix is large
> and I don't have neither control over the projects nor abilities to
> patch them all myself. :)

Sure, I can understand that :-)
> 
> > > Best Regards,
> > > 
> > > David Jaša
> > 
> > Ciao
> > Stephan
> 
> BTW when looking at an old BSI's issue with Linux urandom that Jarod
> Wilson tried to solve with this series:
> https://www.spinics.net/lists/linux-crypto/msg06113.html
> I was thinking:
> 1) wouldn't it help for large urandom consumers if kernel created a DRBG
> instance for each of them? It would likely enhance performance and solve
> BSI's concern of predicting what numbers could other urandom consumers
> obtain at cost of memory footprint

That issue is partly solved with my patch set: I have one DRBG per NUMA node 
where all DRBG instances are equally treated. Surely that patch could be 
expanded on a per-CPU instance. But let us try to use the per-NUMA 
implementation and see whether that helps.

Besides, the legacy /dev/urandom delivers about 12 MB/s on my system whereas 
the DRBG delivers more than 800MB/s. So, we have quite some performance 
improvement.

Note, Ted's patch has a similar implementation.

> and then, after reading paper associated with this series:
> 2) did you evaluate use of intermediate DRBG fed by primary generator to
> instantiate per-node DRBG's? It would allow initialization of all
> secondary DRBGs right after primary generator initialization.

That is exactly what I do.
> 
> Cheers,
> 
> David


Ciao
Stephan