Bug 786407 - [RFE] Add ability to pull system entropy from host
Summary: [RFE] Add ability to pull system entropy from host
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.2
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: Amos Kong
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks: 896690 960054 1056252 786408 883503 969788 973003 973416 973871 989636 989641 1001770 1001773
TreeView+ depends on / blocked
 
Reported: 2012-02-01 11:13 UTC by Steve Grubb
Modified: 2018-12-05 15:28 UTC (History)
26 users (show)

(edit)
Clone Of:
: 969788 973003 973416 973871 989636 989641 1001770 (view as bug list)
(edit)
Last Closed: 2014-10-14 06:47:49 UTC


Attachments (Terms of Use)
simple virtio-rng in RHEL-6 (13.76 KB, patch)
2013-06-07 05:31 UTC, Amos Kong
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1490 normal SHIPPED_LIVE qemu-kvm bug fix and enhancement update 2014-10-14 01:28:27 UTC

Description Steve Grubb 2012-02-01 11:13:25 UTC
Description of problem:
There is a new security requirement that hosts must make available real entropy for use in the guests RNGs. We need to be able to configure this source between at least /dev/urandom and /dev/random on the host.

Comment 1 juzhang 2012-02-01 11:23:23 UTC
Hi,Steve

     Would you please elaborate on this issue and provide an effiecent way  for
qe? thanks

Comment 2 Steve Grubb 2012-02-01 11:55:58 UTC
We have a virtio-rng kernel module for guest use, but qemu does not feed it entropy. So, this bug is asking for the host's /dev/urandom to be read by qemu and sent to the guest's virtio-rng device driver. Testing would probably involve cat /dev/random or something like that and checking the rate at which in delivers random numbers. It should be faster when it has access to system entropy.

Comment 3 Dave Allan 2012-02-01 14:20:38 UTC
What's the qemu interface likely to look like, cmdline only, or is there more involved?

Comment 5 Dave Allan 2012-02-08 17:04:35 UTC
Amit, can you provide an advance view of what the qemu interface is going to look like so we can get the libvirt support done in parallel?  No worries if you end up changing it slightly, anything you can provide is a win for us.

Comment 7 Amit Shah 2012-03-05 09:49:16 UTC
(In reply to comment #5)
> Amit, can you provide an advance view of what the qemu interface is going to
> look like so we can get the libvirt support done in parallel?  No worries if
> you end up changing it slightly, anything you can provide is a win for us.

I'm not yet sure of how it will look.  Anthony had suggested something in the past, though:

http://thread.gmane.org/gmane.comp.emulators.qemu/66830/focus=69160

Quoting;

I agree with Paul that the EGD logic ought to be separated.  It probably 
makes sense to modify this a bit to have a split front-end/back-end.  
For instance:

-device virtio-rng-pci,rngdev=foo -rngdev egd,addr=unix:/path/to/rng,id=foo

You could also have a syntax helper like:

-rng egd,addr:/path/to/rng

Comment 8 Amit Shah 2012-05-16 12:26:09 UTC
First attempt posted at

http://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg02235.html

If this is accepted, the device can be exposed simply by putting

 '-device virtio-rng-pci'

on the command line.

Comment 9 Amit Shah 2012-05-25 19:40:34 UTC
(In reply to comment #2)
> We have a virtio-rng kernel module for guest use, but qemu does not feed it
> entropy. So, this bug is asking for the host's /dev/urandom to be read by
> qemu and sent to the guest's virtio-rng device driver. Testing would
> probably involve cat /dev/random or something like that and checking the
> rate at which in delivers random numbers. It should be faster when it has
> access to system entropy.

virtio-rng is a hardware random number generator, and is not fed into the system entropy pool.  It is instead available via /dev/hwrng on the guest.

Once the virtio-rng device is exposed to the guest, you'll see these:

      $ cat /sys/devices/virtual/misc/hw_random/rng_available
      virtio
    
      $ cat /sys/devices/virtual/misc/hw_random/rng_current
      virtio

And if you do:

      # cat /dev/hwrng

you'll start seeing random data which the host sends.

Comment 10 Amit Shah 2012-06-22 18:57:58 UTC
(In reply to comment #9)
> (In reply to comment #2)
> > We have a virtio-rng kernel module for guest use, but qemu does not feed it
> > entropy. So, this bug is asking for the host's /dev/urandom to be read by
> > qemu and sent to the guest's virtio-rng device driver. Testing would
> > probably involve cat /dev/random or something like that and checking the
> > rate at which in delivers random numbers. It should be faster when it has
> > access to system entropy.
> 
> virtio-rng is a hardware random number generator, and is not fed into the
> system entropy pool.  It is instead available via /dev/hwrng on the guest.
> 
> Once the virtio-rng device is exposed to the guest, you'll see these:
> 
>       $ cat /sys/devices/virtual/misc/hw_random/rng_available
>       virtio
>     
>       $ cat /sys/devices/virtual/misc/hw_random/rng_current
>       virtio
> 
> And if you do:
> 
>       # cat /dev/hwrng
> 
> you'll start seeing random data which the host sends.

Also, running rngd in the guest to feed /dev/hwrng data into guest's /dev/random will speed up all users of /dev/random automatically.

Comment 15 Laine Stump 2012-08-01 19:45:11 UTC
Amit - Is it still the case that the commandline setup upstream will be different from what will be in RHEL6? If so, will there be sufficient info in the -help output to distinguish between the two? (I'm asking because I', the assignee for the libvirt side of this bug - Bug 786408, and libvirt needs to be able to determine at runtime which version to use.)

Comment 16 Amit Shah 2012-08-02 12:30:12 UTC
(In reply to comment #15)
> Amit - Is it still the case that the commandline setup upstream will be
> different from what will be in RHEL6?

That's very likely.

> If so, will there be sufficient info
> in the -help output to distinguish between the two? (I'm asking because I',
> the assignee for the libvirt side of this bug - Bug 786408, and libvirt
> needs to be able to determine at runtime which version to use.)

It will be exposed in -device virtio-rng-pci,? output.

In RHEL6, we'll most likely go with only a chardev property (in addition to common virtio properties).  In RHEL7/upstream, we'll likely have something different, and we don't know yet what it will exactly look like.

Output for -device virtio-rng-pci,? from my RFC backport looks like this:

virtio-rng-pci.indirect_desc=on/off
virtio-rng-pci.event_idx=on/off
virtio-rng-pci.chardev=chr
virtio-rng-pci.addr=pci-devfn
virtio-rng-pci.romfile=string
virtio-rng-pci.rombar=uint32
virtio-rng-pci.multifunction=on/off

Comment 18 juzhang 2012-08-09 02:57:10 UTC
qe will verify this bug(driver) along with bz844583/844582/844579

Comment 19 Laine Stump 2012-08-22 19:47:14 UTC
Amit,

1) is qemu unable to deal with directly specifying /dev/urandom in the chardev option? Or is there some other reason you're sending /dev/urandom into a pipe, then giving the name of the pipe to qemu?

2) once the fd set passing is in qemu, we'll want to be using that for this chardev as well. Will that just automatically work for your code? (My peripheral understanding of those patches is that every use of open/close (and probably some other functions) in qemu is just replaced with calls to qemu_open/qemu_close, etc, so likely it will work, but I wanted to make sure).

3) Will there be any type of rate limiting happening anywhere, to prevent one guest from exhausting all the entropy?

4) Does the build in Comment 14 have what will definitely be in RHEL6.4, or will there still be changes?

Comment 20 Steve Grubb 2012-08-22 22:20:46 UTC
I think there was some discussion in emails early on about rate limiting. I don't see any in this bz. But there should be some way of specifying either the size of a buffer being given to the guest, and/or a delay time between reads. The guest needs some real entropy added to the entropy pool, but not all of its entropy should come from the host. There does need to be some hysteresis or throttle so no one guest can take it all. Thanks.

Comment 21 Amit Shah 2012-08-23 09:13:34 UTC
(In reply to comment #19)
> Amit,
> 
> 1) is qemu unable to deal with directly specifying /dev/urandom in the
> chardev option? Or is there some other reason you're sending /dev/urandom
> into a pipe, then giving the name of the pipe to qemu?

The chardev way is the most flexible: if sysadmins want to use another source, they can wire that up to the chardev instead of /dev/urandom.

> 2) once the fd set passing is in qemu, we'll want to be using that for this
> chardev as well. Will that just automatically work for your code? (My
> peripheral understanding of those patches is that every use of open/close
> (and probably some other functions) in qemu is just replaced with calls to
> qemu_open/qemu_close, etc, so likely it will work, but I wanted to make
> sure).

The changes are generic; they shouldn't change the behaviour for virtio-rng specifically.

> 3) Will there be any type of rate limiting happening anywhere, to prevent
> one guest from exhausting all the entropy?

Since libvirt and other higher layers have information on how many guests there are on the host, I think it makes sense to rate-limit at higher layers as well.  It is expected there will be some way to rate-limit fetching of host entropy.

> 4) Does the build in Comment 14 have what will definitely be in RHEL6.4, or
> will there still be changes?

That's what we'll proceed with unless there are major objections.

Comment 22 Laine Stump 2012-09-07 19:25:46 UTC
The builds referenced in Comment 14 are out of date. Are your patches in an official build yet?

Comment 23 Amit Shah 2012-09-21 03:35:58 UTC
No, the patches aren't posted for review and acceptance yet.

Comment 27 Amit Shah 2012-11-21 13:14:44 UTC
Patches for qemu have been merged upstream.  See qemu.git commits

16c915ba42b45df7a64a6908287f03bfa3764bed
904d6f588063fb5ad2b61998acdf1e73fb465067

Comment 28 Amit Shah 2012-11-28 18:20:30 UTC
The upstream interface is different from what was discussed earlier here.  More information on how things work upstream is documented at

http://wiki.qemu.org/Features/VirtIORNG

Comment 37 Amos Kong 2013-06-07 05:31:37 UTC
Created attachment 757986 [details]
simple virtio-rng in RHEL-6

Just implemented a simple virtio-rng in RHEL-6 as a reference.
go on to face the conflicts in backporting QOM/QAPI infrastructure.

Comment 39 Tahlia Richardson 2013-06-12 00:17:08 UTC
Marking with docs_scoped ? 
Amos, should this be documented in the Virtualization Host Configuration and Guest Installation Guide?

Comment 40 Amos Kong 2013-06-13 02:22:22 UTC
(In reply to trichard from comment #39)
> Marking with docs_scoped ? 
> Amos, should this be documented in the Virtualization Host Configuration and
> Guest Installation Guide?

Yes, it's needed.

Comment 41 Laura Novich 2013-06-16 12:05:49 UTC
Ademar - should this QEMU-KVM component be documented in any of the RHEL Virt. Docs? or just the whitelist?

Comment 42 Ademar Reis 2013-06-17 14:45:36 UTC
(In reply to Laura Novich from comment #41)
> Ademar - should this QEMU-KVM component be documented in any of the RHEL
> Virt. Docs? or just the whitelist?

Yes, it should be documented. It's a new feature and is exposed to users.

Comment 57 Miroslav Rezanina 2014-01-27 07:50:47 UTC
Fix included in qemu-kvm-0.12.1.2-2.420.el6

Comment 58 Miroslav Rezanina 2014-01-27 07:51:39 UTC
Fix included in qemu-kvm-0.12.1.2-2.420.el6

Comment 62 errata-xmlrpc 2014-10-14 06:47:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1490.html


Note You need to log in before you can comment on or make changes to this bug.