linux-kernel - Re: [PATCH 07/10] random: add new get_random_bytes

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:	Tue, 24 Jul 2012 20:37:23 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Theodore Ts'o" <tytso@....edu>
CC:	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	torvalds@...ux-foundation.org, w@....eu, ewust@...ch.edu,
	zakir@...ch.edu, greg@...ah.com, mpm@...enic.com,
	nadiah@...ucsd.edu, jhalderm@...ch.edu, tglx@...utronix.de,
	davem@...emloft.net, stable@...nel.org,
	DJ Johnson <dj.johnson@...el.com>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 07/10] random: add new get_random_bytes_arch() function

For those who have read the Google+ thread[1] it is pretty clear that 
there are varying opinions on the idea of removing the RDRAND bypass.

I have gathered some performance numbers to make the debate more 
concrete: RDRAND is between 12 and 15 times faster than the current 
random pool system (for large and small blocks, respectively.)  Both the 
pool system and RDRAND scale perfectly with frequency, so the ratio is 
independent of P-states.

Given the discrepancy in performance (and presumably, in terms of power) 
I still very much believe it is a mistake to unconditionally disallow 
users the option for using RDRAND directly, but what I *do* believe we 
can all agree on is that security is paramount.  Dropping RDRAND is not 
just a performance loss but is likely a security loss since it will 
produce substantially less entropy.

As a compromise I offer the following patch; in terms of performance it 
is "the worst of both worlds" but it should provide the combined 
security of either; even if RDRAND is completely compromised by the NSA, 
Microsoft and the Illuminati all at once it will do no worse than the 
existing code, and (since RDRAND is so much faster than the existing 
code) it has only a modest performance cost.  More realistically, it 
will let many more users take advantage of a high entropy 
quick-reseeding random number generator, thus ending up with a major 
gain in security.

It is worth noting that although RDRAND by itself is adequate for any 
in-kernel users (and the 3.4-3.5 kernels use them as such unless you 
specify "nordrand"), this is not true for /dev/random; nor, due to 
abuse, /dev/urandom; the recently disclosed[2] RDSEED instruction, on 
the other hand, is defined to be fully entropic and can be used for any 
purpose; that one will be introduced in a later processor.

Note that the attached patch is way more conservative than it needs to 
be: every byte is mixed with RDRAND data twice on its way through (and 
an additional 1.2 byte is lost), as I moved the mixing to extract_buf(), 
but even so the overhead is modest, and mixing in extract_buf() makes 
the code quite a bit simpler.

This patch is on top of random.git.

[1] https://plus.google.com/115124063126128475540/posts/KbAEJKMsAfq

[2] http://software.intel.com/file/45207

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

View attachment "0001-random-mix-in-architectural-randomness-in-extract_bu.patch" of type "text/x-patch" (5198 bytes)