linux-kernel - Re: [RFD] Direct support for the x86 RDRAND instruction

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:	Fri, 29 Jul 2011 14:17:14 -0700
From:	"H. Peter Anvin" <hpa@...ux.intel.com>
To:	Jeff Garzik <jgarzik@...ox.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Fenghua Yu <fenghua.yu@...el.com>,
	Matt Mackall <mpm@...enic.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Theodore Ts'o <tytso@....edu>, linux-kernel@...r.kernel.org
Subject: Re: [RFD] Direct support for the x86 RDRAND instruction

On 07/29/2011 02:05 PM, Jeff Garzik wrote:
> 
> This does not cover the one question I [predictably] have:  why not do 
> this in rngd, rather than the kernel?
> 

That is actually why I didn't do the /dev/random aspect of this.  I have
an rngd enabling patch in the works as well.

The reason for not using RDRAND *only* in rngd is that it is a poor
match -- RDRAND is designed as a /dev/urandom-type replacement, but it
is *way* faster than the in-kernel system (since it is all in
hardware)... plus it is reseeded far more frequently than what is
possible in software (the architectural spec guarantees a reseed every
512 reads; I am told by the hardware people that in reality it is way
more frequent than that.)

For /dev/random, we do want to be hyper-conservative, though.  rngd in
its current form doesn't deal with fractional entropy, which means
boiling it down to guaranteed pure entropy; this is an enormous data
reduction and about three orders of magnitude reduction in bandwidth.
For /dev/random, I think that is just fine; after all, if you're asking
for /dev/random, you're asking for security at every cost.

> Since many (all?) TPM chips include a random number generator, Dell has 
> made sure that most distros have a useful copy of the rng-tools 
> userspace pkg I've been maintaining.
> 
> It would seem straightforward to add this to rngd, and enable RDRAND on 
> older distros and kernels, as well as current distros / kernels.  This 
> also gets useful entropy to /dev/random as part of normal operation, 
> rather than only merely speeding up /dev/urandom.
> 
> Though for the record, I do agree that this is a nice, small and clean 
> kernel implementation.

As previously stated, I have that patch in the works as well.

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