[Feature] RDRAND enabling for rngd

Bug #1084378 reported by Yingying Zhao on 2012-11-29
This bug affects 1 person
Affects Status Importance Assigned to Milestone
rng-tools (Ubuntu)
Tim Gardner
Tim Gardner

Bug Description

Enable the random number generator daemon (rngd) to take advantage of entropy provided by RDRAND.

RDRAND support in rngd is now released in upstream: http://sourceforge.net/projects/gkernel/files/rng-tools/4/

But Debian Debian community is maintaining a separated/unofficial branch of "rng-tools" from the above official repos. So this feature is to request RDRAND support in Ubuntu's "rng-tools".

Yingying Zhao (yingying-zhao) wrote :

@Canonical, who can help to look at this feature request for Raring?

Changed in intel:
importance: Undecided → Medium
XiongZhang (xiong-y-zhang) wrote :

@Canonical, will the rng-tools package be updated in Saucy so that it can contain this feature ?

information type: Proprietary → Private
XiongZhang (xiong-y-zhang) wrote :

I make a request to debian rng-tools maintainer for updating this package, but there is no response from him. This package on debian community hasn't been updated for two years. But the upstream rng-tools are always updated. So it's better for ubuntu to update this package yourself.

Tim Gardner (timg-tpi) on 2013-08-13
information type: Private → Public
Changed in rng-tools (Ubuntu Saucy):
assignee: nobody → Tim Gardner (timg-tpi)
status: New → In Progress
Tim Gardner (timg-tpi) on 2013-08-13
Changed in rng-tools (Ubuntu Saucy):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rng-tools - 4-0ubuntu1

rng-tools (4-0ubuntu1) saucy; urgency=low

  * Merge from upstream git://git.kernel.org/pub/scm/utils/kernel/rng-tools/rng-tools.git
    -LP: #1084378
 -- Tim Gardner <email address hidden> Tue, 13 Aug 2013 13:12:05 +0000

Changed in rng-tools (Ubuntu Saucy):
status: Fix Committed → Fix Released
Changed in intel:
status: New → Fix Released
Nathan Dorfman (ndorf) wrote :

Hello. Sorry to be the bearer of bad news, but this implementation is broken in a subtle but important way:

When adding the data returned from rdrand to the system entropy pool, using the RNDADDENTROPY ioctl on /dev/random, it sets the entropy count equal to the buffer size. In other words, claiming that its data is 100% entropy.

This is clearly wrong, as the rdrand instruction only gives access to a deterministic pseudo-random number generator. It's seeded by a built-in hardware source of true entropy, but the rdrand instruction doesn't give access to the output of the entropy source, only to the output of PRNG.

The PRNG is reseeded often from this entropy source, so the output contains plenty of entropy, but nowhere near 100% (or even 1%). Intel states that you are guaranteed a reseed if you invoke the 64-bit rdrand instruction more than 1022 times (http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide). A seed value is 256 bits. So in the worst case, we are providing 256 bits of entropy per almost 8KB of rdrand output. The problem is, when we pass it to the kernel, we claim that we provided 8KB of entropy:

(from rngd_linux.c):
    entropy.ent_count = size * 8;
    entropy.size = size;

The solution would be simple: per each ioctl(), make sure we've called rdrand64 more than 1022 times, and set the ent_count to 256.

This can actually be done using command line options in the "official" (git://git.kernel.org/pub/scm/utils/kernel/rng-tools/rng-tools.git) rng-tools, but not the version in this Ubuntu package. They have a command line option -H that lets you specify the "entropy per bit" as a floating point, which we are missing. In conjunction with the random-step option -s, the correct behavior can be coaxed out of it by using -H 0.0039062500 -s 8192. Pretty klugy, though.

I also found GPL code (I don't know the author) at https://github.com/bjencks/rngd-rdrand which cleanly and correctly does the right thing. It only supports rgrand, no other sources, so the whole thing is about 100 lines of C. It isn't productionized (doesn't fork into the background, doesn't have an init.d script, etc.) but I'm using it on my system almost as-is, and it is still fast enough to generate 2048-bit GPG key pairs nearly instantaneously on my system. The only change I made was to bump the number of rdrands per ioctl to 1024 from 1022, as the Intel docs linked above say *more* than 1022, not just 1022.

XiongZhang (xiong-y-zhang) wrote :

>This can actually be done using command line options in the "official" (git://git.kernel.org/pub/scm/utils/kernel/rng-tools
> /rng-tools.git) rng-tools, but not the version in this Ubuntu package.

From commend #4, the rng-tools in Ubuntu 13.10 is the same as "official" upstream. Does rng-tools in ubuntu 13.10 still have the issue your mentioned ?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers