Bug 786407
Summary: | [RFE] Add ability to pull system entropy from host | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Steve Grubb <sgrubb> | ||||
Component: | qemu-kvm | Assignee: | Amos Kong <akong> | ||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 6.2 | CC: | ailan, akong, areis, bcao, b.j.smith, bsarathy, dayleparker, juzhang, kseifried, laine, lnovich, mazhang, mhomolov, michen, mkalinin, mkenneth, pkrempa, pspacek, qzhang, rbalakri, sgrubb, shu, sradvan, tburke, trichard, virt-maint | ||||
Target Milestone: | rc | Keywords: | FutureFeature | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | qemu-kvm-0.12.1.2-2.420.el6 | Doc Type: | Enhancement | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 969788 973003 973416 973871 989636 989641 1001770 (view as bug list) | Environment: | |||||
Last Closed: | 2014-10-14 06:47:49 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 896690, 786408, 883503, 960054, 969788, 973003, 973416, 973871, 989636, 989641, 1001770, 1001773, 1056252 | ||||||
Attachments: |
|
Description
Steve Grubb
2012-02-01 11:13:25 UTC
Hi,Steve Would you please elaborate on this issue and provide an effiecent way for qe? thanks 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. What's the qemu interface likely to look like, cmdline only, or is there more involved? 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. (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 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. (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. (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. 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.) (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 qe will verify this bug(driver) along with bz844583/844582/844579 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? 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. (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. The builds referenced in Comment 14 are out of date. Are your patches in an official build yet? No, the patches aren't posted for review and acceptance yet. Patches for qemu have been merged upstream. See qemu.git commits 16c915ba42b45df7a64a6908287f03bfa3764bed 904d6f588063fb5ad2b61998acdf1e73fb465067 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 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.
Marking with docs_scoped ? Amos, should this be documented in the Virtualization Host Configuration and Guest Installation Guide? (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. Ademar - should this QEMU-KVM component be documented in any of the RHEL Virt. Docs? or just the whitelist? (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. Fix included in qemu-kvm-0.12.1.2-2.420.el6 Fix included in qemu-kvm-0.12.1.2-2.420.el6 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 |