linux-kernel - Re: [PATCH] random: add blocking facility to urandom

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, 8 Sep 2011 09:11:12 -0400
From:	Steve Grubb <sgrubb@...hat.com>
To:	Neil Horman <nhorman@...hat.com>
Cc:	Tomas Mraz <tmraz@...hat.com>,
	Sasha Levin <levinsasha928@...il.com>,
	"Ted Ts'o" <tytso@....edu>, Jarod Wilson <jarod@...hat.com>,
	linux-crypto@...r.kernel.org, Matt Mackall <mpm@...enic.com>,
	Herbert Xu <herbert.xu@...hat.com>,
	Stephan Mueller <stephan.mueller@...ec.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] random: add blocking facility to urandom

On Thursday, September 08, 2011 08:52:34 AM Neil Horman wrote:
> > to disk device - of course only if the device adds entropy into the
> > primary pool when there are writes on the device.
> 
> Yes, and thats a problem.  We're assuming in the above case that writes to
> disk generate interrupts which in turn generate entropy in the pool.  If
> that happens, then yes, it can be difficult (though far from impossible)
> to block on urandom with this patch and a sufficiently high blocking
> threshold.  But interrupt randomness is only added for interrupts flagged
> with
> IRQF_SAMPLE_RANDOM, and if you look, almost no hard irqs add that flag.  So
> its possible (and even likely) that writing to disk will not generate
> additional entropy.

The system being low on entropy is another problem that should be addressed. For our 
purposes, we cannot say take it from TPM or RDRND or any plugin board. We have to have 
the mathematical analysis that goes with it, we need to know where the entropy comes 
from, and a worst case entropy estimation. It has to be documented in detail. The only 
way we can be certain is if its based on system events. Linux systems are constantly 
low on entropy and this really needs addressing. But that is a separate issue. For 
real world use, I'd recommend everyone use a TPM chip + rngd and you'll never be short 
on random numbers. But in the case where we are certifying the OS, we need the 
mathematical argument to prove that unaided, things are correct.

> > Of course you can still easily make the /dev/urandom to occasionally
> > block with this patch, just read the data and drop it.
> > 
> > But you have to understand that the value that will be set with the
> > sysctl added by this patch will be large in the order of millions of
> > bits.
> 
> You can guarantee that?  

One proposal I made to Jarod was to add some minimum threshold that would prevent 
people from setting a value of 2, for example. Maybe the threshold could be set at 64K 
or higher depending on what number we get back from BSI.

> This sysctl allows for a setting of 2 just as  easily as it allows for a setting of
> 8,000,000.  And the former is sure to break or otherwise adversely affect
> applications that expect urandom to never block. Thats what Sasha was referring to,
> saying that patch makes it easy for admins to make serious mistakes.

Would a sufficiently high threshold make this easier to accept?

-Steve

--
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/