[Qemu-devel] virtio-rng async rng_backend_request_entropy() vs migration
Dave Gilbert hit the following virtio migration error message today and asked me if it was a known bug: virtio-rng: VQ 0 size 0x8 < last_avail_idx 0x21 - used_idx 0x22 It looks like a legitimate new bug. This error occurred with postcopy live migration and no rng backend (just -device virtio-rng-pci). The virtio-rng code uses rng_backend_request_entropy(). Is the async callback safe with live migration? It should not fire after vm_stop() on the source host. Looking briefly at the code suggests it may fire during/after migration handover. This could lead to inconsistent virtio state since the vring (guest RAM) is modified by the source host and the postcopy destination host may load those updated values. Stefan
Re: [Qemu-devel] virtio-rng and fd passing
On (Fri) 01 Mar 2013 [10:51:33], Paolo Bonzini wrote: Il 01/03/2013 01:36, Eric Blake ha scritto: For fd passing to work, we have to use qemu_open() instead of raw open(). Is there any way to enforce that all files being opened by qemu go through the appropriate qemu_open() wrapper? Meanwhile, we have a quandary on the libvirt side of things: qemu 1.4 supports fd passing in general, but does not support it for rng. I guess the same is true for -blockdev - we don't (yet) have a way to do fd passing for backing files. Do we need some sort of QMP command that will let libvirt query for a particular device whether that device is known to support fd passing, so that libvirt can use fd passing for all supported devices, while falling back to older direct open()s, and to know which instance of qemu can safely have open() blocked at the SELinux or syscall blacklist level? Let's change open to qemu_open for 1.4.1, and declare rng only supported in 1.4.1... There are a few bugs that prevent the rng-random backend from working properly. I suspect we should move to using giochannel for the fd. https://bugzilla.redhat.com/show_bug.cgi?id=917884 (issuing 'cat /dev/random' in host hits an assert and kills guest) https://bugzilla.redhat.com/show_bug.cgi?id=917886 (default /dev/random backend doesn't send data to guest) https://bugzilla.redhat.com/show_bug.cgi?id=915381 (performance of backends sucks) Amit
Re: [Qemu-devel] virtio-rng and fd passing
On Fri, Mar 01, 2013 at 04:14:40PM -0700, Eric Blake wrote: I understand the reason that fdsets exist (because NFS is stupid and doesn't support labeling). But we aren't doing dynamic labeling of /dev/random and I strongly suspect it's not on NFS anyway. So why are we trying to pass fds here? Consistency - how do you write a policy that allows open(/dev/random) while forbidding open(/nfs/...)? It's much simpler to forbid open(), even if /dev/random doesn't have any labeling issues. IIUC, it is actually pretty straightforward from a policy POV. Every filesystem has a unique type, and SELinux can make rules scoped to that filesystem type. That's how we have the 'virt_use_nfs' tunable already which only affects NFS. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] virtio-rng and fd passing
On 03/04/2013 05:29 AM, Daniel P. Berrange wrote:
On Fri, Mar 01, 2013 at 04:14:40PM -0700, Eric Blake wrote:
I understand the reason that fdsets exist (because NFS is stupid and
doesn't support labeling). But we aren't doing dynamic labeling of
/dev/random and I strongly suspect it's not on NFS anyway.
So why are we trying to pass fds here?
Consistency - how do you write a policy that allows open(/dev/random)
while forbidding open(/nfs/...)? It's much simpler to forbid open(),
even if /dev/random doesn't have any labeling issues.
IIUC, it is actually pretty straightforward from a policy POV. Every
filesystem has a unique type, and SELinux can make rules scoped to that
filesystem type. That's how we have the 'virt_use_nfs' tunable already
which only affects NFS.
Daniel
Yes it should be simple, at least for SELinux. I think all we need to
do is remove open permission from the qemu process (svirt_t) on NFS
files (files labeled with nfs_t).
Here's what I see for base qemu permissions on NFS files on Fedora 18:
$ sesearch -A -s svirt_t -t nfs_t | grep : file | grep open
allow virt_domain nfs_t : file { ioctl read write create getattr
setattr lock append unlink link rename open } ;
And I think 'setsebool -P virt_use_nfs 0' will remove the open
permission, so this may already be covered.
I'm not sure how easy it is for other MAC implementations. Last I
checked AppArmor didn't have the granularity of preventing open and
allowing read/write.
--
Regards,
Corey Bryant
Re: [Qemu-devel] virtio-rng and fd passing
On 03/01/2013 10:34 PM, Stefan Berger wrote: On 03/01/2013 10:17 PM, Anthony Liguori wrote: Stefan Berger stef...@linux.vnet.ibm.com writes: On 03/01/2013 06:59 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 04:05 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 02:08 PM, Anthony Liguori wrote: You can pass chardevs to the egd backend. It's really not a good idea to pass a fd via rng-rangom. Why not? If you are running a single guest, why can't libvirt pass that one guest an fd instead of making qemu open() the file? Why can't QEMU just open(/dev/random)? What's the advantage of libvirt doing the open? sVirt/syscall blacklisting Libvirt WANTS to prohibit qemu from using open()/openat(), and instead get ALL its fds from inheritence across exec() and/or SCM_RIGHTS. In this way, qemu can be made more secure out of the box, even on file systems like NFS that lack SELinux labeling. Opening up files as root and passing the descriptors to an unprivileged process is more secure than doing open() as an unprivileged process. The kernel is capable of doing this enforcement. I don't think it's reasonable to expect QEMU to never use open() at all. For blacklisting of open() to succeed we would need to at least pass all file descriptors into QEMU so that QEMU doesn't need to call open() because of the devices it uses. If there are no open() calls left in all/most predictable cases then blacklisting open() could be enabled for those cases (hopefully all of them). Isn't thos the technical aspect to what it comes down to in the end that would let one blacklist open()? Sandboxing isn't a panacea. The benefit comes from removing unnecessary interfaces from the attack surface. It doesn't help if you blacklist and interface but then invent an RPC that replicates it anyway. Moving the open validation logic from the kernel to libvirt is *not* reducing the attack surface. It's simply moving it from one place (the kernel) to another (libvirt). It depends on what one defends against. If a jail-break succeeds and open() is disabled, then that attack surfaces was effectively reduced. It's hard to say whether opening files within libvirt could then allow new exploits. Stefan Agreed. And this all assumes that libvirt is trusted. The goal is to prevent a malicious qemu guest from opening something that does not belong to it. So we either prevent all qemu open()s with seccomp (which may not be realistic at this point) or we prevent them on a case by case basis with MAC (e.g. prevent qemu from opening files labeled with SELinux type nfs_t) where sVirt does not already have us covered. -- Regards, Corey Bryant
Re: [Qemu-devel] virtio-rng and fd passing
On 03/01/2013 08:13 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 04:59 PM, Anthony Liguori wrote: I said this when seccomp was first introduced and I'll say it again. blacklisting open() is a bad idea. DAC and MAC already exist and solve this problem. We've got filesystem namespaces too. Let's explore that idea a bit further. What happens if libvirt decides to create a new filesystem namespace for qemu, where libvirt unmounts all non-local filesystems, as well as any file system that does not support SELinux labeling. Then all remaining filesystems, seen by qemu, will enforce SELinux semantics, and we can let qemu open() at will because the open will then be guarded by SELinux. The only remaining access is to files to the unmounted file systems, where fd passing from libvirt bypasses the fact that qemu can't see the file system. I could see that working, and it would still let us get rid of the selinux virt_use_nfs bool while still providing secure NFS out-of-the-box. And your argument is that virtio-rng should be pointed to a character device, never an NFS file, and therefore not using qemu_open() is no real loss because open() will not be blacklisted, just NFS file systems. Okay, maybe that will work. A simpler version would be to chroot the QEMU process but sure. chroot is escapable, but you are correct that there are indeed ways of restricting open() on certain filesystems without blacklisting all open() in general. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] virtio-rng and fd passing
[adding libvirt] On 03/03/2013 02:05 PM, Anthony Liguori wrote: Paolo Bonzini pbonz...@redhat.com writes: Il 02/03/2013 04:13, Anthony Liguori ha scritto: There is no valid use-case of rng-random other than using /dev/random. In fact, it was probably a mistake to even allow a filename to be specified because it lets people do silly things (like /dev/urandom). If you want anything other than /dev/random, you should use rng-egd. /dev/hwrng makes sense too. Good point. Perhaps we should issue a warning when anything is used other than /dev/random or /dev/hwrng to discourage people from doing the wrong thing. I completely understand the confusion and I think we should try a bit harder to prevent people from getting it wrong. Then libvirt should also make sure that the XML we allow for non-egd virtio-rng is restricted to the two filenames that won't cause a qemu warning, or even modify the XML to not expose a filename in the first place. We haven't released libvirt 1.0.3 yet, so we still have a few hours in which such a change could be made before the XML becomes baked by a release. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] virtio-rng and fd passing
Eric Blake ebl...@redhat.com writes: [adding libvirt] On 03/03/2013 02:05 PM, Anthony Liguori wrote: Paolo Bonzini pbonz...@redhat.com writes: Il 02/03/2013 04:13, Anthony Liguori ha scritto: There is no valid use-case of rng-random other than using /dev/random. In fact, it was probably a mistake to even allow a filename to be specified because it lets people do silly things (like /dev/urandom). If you want anything other than /dev/random, you should use rng-egd. /dev/hwrng makes sense too. Good point. Perhaps we should issue a warning when anything is used other than /dev/random or /dev/hwrng to discourage people from doing the wrong thing. I completely understand the confusion and I think we should try a bit harder to prevent people from getting it wrong. Then libvirt should also make sure that the XML we allow for non-egd virtio-rng is restricted to the two filenames that won't cause a qemu warning, or even modify the XML to not expose a filename in the first place. We haven't released libvirt 1.0.3 yet, so we still have a few hours in which such a change could be made before the XML becomes baked by a release. We've already released QEMU accepting any file name so we can't remove that functionality but I'm very much leaning toward producing such a warning for 1.5. It's such an easy mistake to make and it's extremely difficult to find good information on what you should and shouldn't do. I think that we (QEMU and libvirt) should try hard to steer people in the right direction. Regards, Anthony Liguori -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] virtio-rng and fd passing
On 03/04/2013 03:24 PM, Anthony Liguori wrote: Then libvirt should also make sure that the XML we allow for non-egd virtio-rng is restricted to the two filenames that won't cause a qemu warning, or even modify the XML to not expose a filename in the first place. We haven't released libvirt 1.0.3 yet, so we still have a few hours in which such a change could be made before the XML becomes baked by a release. We've already released QEMU accepting any file name so we can't remove that functionality but I'm very much leaning toward producing such a warning for 1.5. It's such an easy mistake to make and it's extremely difficult to find good information on what you should and shouldn't do. I think that we (QEMU and libvirt) should try hard to steer people in the right direction. It's too late for qemu 1.4, but libvirt 1.0.3 can still get it right. Proposed libvirt patch coming up soon. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] virtio-rng and fd passing
On 03/02/2013 04:23 AM, Paolo Bonzini wrote: Il 02/03/2013 04:13, Anthony Liguori ha scritto: There is no valid use-case of rng-random other than using /dev/random. In fact, it was probably a mistake to even allow a filename to be specified because it lets people do silly things (like /dev/urandom). If you want anything other than /dev/random, you should use rng-egd. /dev/hwrng makes sense too. Only if the host isn't using it, which it almost certainly should if there is something there. On the other hand, yes, it is cryptographically sound (since it presents itself as /dev/hwrng in the guest!) and it does make sense for a very thin host. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Re: [Qemu-devel] virtio-rng and fd passing
Paolo Bonzini pbonz...@redhat.com writes: Il 02/03/2013 04:13, Anthony Liguori ha scritto: There is no valid use-case of rng-random other than using /dev/random. In fact, it was probably a mistake to even allow a filename to be specified because it lets people do silly things (like /dev/urandom). If you want anything other than /dev/random, you should use rng-egd. /dev/hwrng makes sense too. Good point. Perhaps we should issue a warning when anything is used other than /dev/random or /dev/hwrng to discourage people from doing the wrong thing. I completely understand the confusion and I think we should try a bit harder to prevent people from getting it wrong. Regards, Anthony Liguori Paolo
Re: [Qemu-devel] virtio-rng and fd passing
Stefan Berger stef...@linux.vnet.ibm.com writes: It depends on what one defends against. If a jail-break succeeds and open() is disabled, then that attack surfaces was effectively reduced. It's hard to say whether opening files within libvirt could then allow new exploits. Well, in the very least, libvirt is doing the open() as root whereas QEMU does it as an unprivileged user. Regards, Anthony Liguori Stefan
Re: [Qemu-devel] virtio-rng and fd passing
On (Fri) 01 Mar 2013 [10:51:33], Paolo Bonzini wrote: Il 01/03/2013 01:36, Eric Blake ha scritto: For fd passing to work, we have to use qemu_open() instead of raw open(). Is there any way to enforce that all files being opened by qemu go through the appropriate qemu_open() wrapper? Meanwhile, we have a quandary on the libvirt side of things: qemu 1.4 supports fd passing in general, but does not support it for rng. I guess the same is true for -blockdev - we don't (yet) have a way to do fd passing for backing files. Do we need some sort of QMP command that will let libvirt query for a particular device whether that device is known to support fd passing, so that libvirt can use fd passing for all supported devices, while falling back to older direct open()s, and to know which instance of qemu can safely have open() blocked at the SELinux or syscall blacklist level? Let's change open to qemu_open for 1.4.1, and declare rng only supported in 1.4.1... In addition, we can tweak checkpatch.pl to flag such usage as a warning. Amit
Re: [Qemu-devel] virtio-rng and fd passing
Il 02/03/2013 04:13, Anthony Liguori ha scritto: There is no valid use-case of rng-random other than using /dev/random. In fact, it was probably a mistake to even allow a filename to be specified because it lets people do silly things (like /dev/urandom). If you want anything other than /dev/random, you should use rng-egd. /dev/hwrng makes sense too. Paolo
Re: [Qemu-devel] virtio-rng and fd passing
Il 01/03/2013 01:36, Eric Blake ha scritto: For fd passing to work, we have to use qemu_open() instead of raw open(). Is there any way to enforce that all files being opened by qemu go through the appropriate qemu_open() wrapper? Meanwhile, we have a quandary on the libvirt side of things: qemu 1.4 supports fd passing in general, but does not support it for rng. I guess the same is true for -blockdev - we don't (yet) have a way to do fd passing for backing files. Do we need some sort of QMP command that will let libvirt query for a particular device whether that device is known to support fd passing, so that libvirt can use fd passing for all supported devices, while falling back to older direct open()s, and to know which instance of qemu can safely have open() blocked at the SELinux or syscall blacklist level? Let's change open to qemu_open for 1.4.1, and declare rng only supported in 1.4.1... Paolo
Re: [Qemu-devel] virtio-rng and fd passing
On 02/28/2013 04:36 PM, Eric Blake wrote: Stefan Berger and I discovered on IRC that virtio-rng is unable to support fd passing. We attempted: qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom -object rng-random,id=rng0,filename=/dev/fdset/4 -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6 Unrelated, but you really, really, really don't want to pass /dev/urandom there, use /dev/random. -hpa
Re: [Qemu-devel] virtio-rng and fd passing
Eric Blake ebl...@redhat.com writes:
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
-object rng-random,id=rng0,filename=/dev/fdset/4 -device
virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6
Why are you using th rng-random backend instead of the rng-egd backend?
You can pass chardevs to the egd backend. It's really not a good idea
to pass a fd via rng-rangom.
Regards,
Anthony Liguori
qemu-system-x86_64: -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6:
Could not open '/dev/fdset/4'
Looks like this code is the culprit, in backends/rng-random.c:
static void rng_random_opened(RngBackend *b, Error **errp)
{
RndRandom *s = RNG_RANDOM(b);
if (s-filename == NULL) {
error_set(errp, QERR_INVALID_PARAMETER_VALUE,
filename, a valid filename);
} else {
s-fd = open(s-filename, O_RDONLY | O_NONBLOCK);
For fd passing to work, we have to use qemu_open() instead of raw
open(). Is there any way to enforce that all files being opened by qemu
go through the appropriate qemu_open() wrapper?
Meanwhile, we have a quandary on the libvirt side of things: qemu 1.4
supports fd passing in general, but does not support it for rng. I
guess the same is true for -blockdev - we don't (yet) have a way to do
fd passing for backing files. Do we need some sort of QMP command that
will let libvirt query for a particular device whether that device is
known to support fd passing, so that libvirt can use fd passing for all
supported devices, while falling back to older direct open()s, and to
know which instance of qemu can safely have open() blocked at the
SELinux or syscall blacklist level?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] virtio-rng and fd passing
On 03/01/2013 02:37 PM, H. Peter Anvin wrote: On 02/28/2013 04:36 PM, Eric Blake wrote: Stefan Berger and I discovered on IRC that virtio-rng is unable to support fd passing. We attempted: qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom -object rng-random,id=rng0,filename=/dev/fdset/4 -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6 Unrelated, but you really, really, really don't want to pass /dev/urandom there, use /dev/random. From what I am reading about /dev/random is that it will start blocking once not enough entropy is available anymore. Sounds like this could be abused if multiple VMs were using this device and one drains the entropy.. An alternative may be to pick go through a crypto library that seeds itself with entropy and implements random number generators following NIST 800-90 for example. Freebl would offer at least one such implementation: http://dxr.mozilla.org/mozilla-central/security/nss/lib/freebl/drbg.c.html - search for 'NIST' there Stefan
Re: [Qemu-devel] virtio-rng and fd passing
The guest kernel already provides the PRNG itself. We have been over this... Stefan Berger stef...@linux.vnet.ibm.com wrote: On 03/01/2013 02:37 PM, H. Peter Anvin wrote: On 02/28/2013 04:36 PM, Eric Blake wrote: Stefan Berger and I discovered on IRC that virtio-rng is unable to support fd passing. We attempted: qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom -object rng-random,id=rng0,filename=/dev/fdset/4 -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6 Unrelated, but you really, really, really don't want to pass /dev/urandom there, use /dev/random. From what I am reading about /dev/random is that it will start blocking once not enough entropy is available anymore. Sounds like this could be abused if multiple VMs were using this device and one drains the entropy.. An alternative may be to pick go through a crypto library that seeds itself with entropy and implements random number generators following NIST 800-90 for example. Freebl would offer at least one such implementation: http://dxr.mozilla.org/mozilla-central/security/nss/lib/freebl/drbg.c.html - search for 'NIST' there Stefan -- Sent from my mobile phone. Please excuse brevity and lack of formatting.
Re: [Qemu-devel] virtio-rng and fd passing
On 03/01/2013 03:04 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: Stefan Berger and I discovered on IRC that virtio-rng is unable to support fd passing. We attempted: qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom -object rng-random,id=rng0,filename=/dev/fdset/4 -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6 Why are you using th rng-random backend instead of the rng-egd backend? I followed the example on the libvirt website trying out the XML for the rng device while adpating the libvirt code to use fd passing and generating the -add-fd command line parameters. You can pass chardevs to the egd backend. It's really not a good idea to pass a fd via rng-rangom. Fine, then we won't use fd passing for this device, whatever the reason may be. Stefan
Re: [Qemu-devel] virtio-rng and fd passing
Il 01/03/2013 21:13, Stefan Berger ha scritto: On 03/01/2013 02:37 PM, H. Peter Anvin wrote: On 02/28/2013 04:36 PM, Eric Blake wrote: Stefan Berger and I discovered on IRC that virtio-rng is unable to support fd passing. We attempted: qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom -object rng-random,id=rng0,filename=/dev/fdset/4 -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6 Unrelated, but you really, really, really don't want to pass /dev/urandom there, use /dev/random. From what I am reading about /dev/random is that it will start blocking once not enough entropy is available anymore. Yes, and the purpose of virtio-rng is not to provide fancy random numbers. It's to provide actual entropy. Paolo
Re: [Qemu-devel] virtio-rng and fd passing
Stefan Berger stef...@linux.vnet.ibm.com writes: On 03/01/2013 03:04 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: Stefan Berger and I discovered on IRC that virtio-rng is unable to support fd passing. We attempted: qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom -object rng-random,id=rng0,filename=/dev/fdset/4 -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6 Why are you using th rng-random backend instead of the rng-egd backend? I followed the example on the libvirt website trying out the XML for the rng device while adpating the libvirt code to use fd passing and generating the -add-fd command line parameters. You can pass chardevs to the egd backend. It's really not a good idea to pass a fd via rng-rangom. Fine, then we won't use fd passing for this device, whatever the reason may be. So let's step back. There are two backends currently supported: rng-random and rng-egd. I don't see any point in taking an fd for rng-random. I don't think labeling comes into play here. But if libvirt wants to interact with virtio-rng in a more intelligent way (implementing a policy to distribute entropy), then rng-egd is the right way to do that. Regards, Anthony Liguori Stefan
Re: [Qemu-devel] virtio-rng and fd passing
On 03/01/2013 02:08 PM, Anthony Liguori wrote: You can pass chardevs to the egd backend. It's really not a good idea to pass a fd via rng-rangom. Why not? If you are running a single guest, why can't libvirt pass that one guest an fd instead of making qemu open() the file? Fine, then we won't use fd passing for this device, whatever the reason may be. So let's step back. There are two backends currently supported: rng-random and rng-egd. I don't see any point in taking an fd for rng-random. I don't think labeling comes into play here. But if libvirt wants to interact with virtio-rng in a more intelligent way (implementing a policy to distribute entropy), then rng-egd is the right way to do that. Yes, libvirt will probably use rng-egd when distributing randomness among multiple guests. But libvirt wants to target BOTH forms of rng, in order to let the user choose which one is best for their needs. If rng-random is not useful to any end user, then why did qemu expose it in the first place? And if qemu thought it was worth exposing, then libvirt thinks it is worth targetting, and by using qemu_open instead of raw open, then fd passing is possible. Policy (whether it makes sense to pass an fd for a random generator, and whether /dev/random or /dev/urandom or something else is best) may be important, but it is orthogonal to the issue that I raised about consistency. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] virtio-rng and fd passing
On 03/01/13 21:04, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: Stefan Berger and I discovered on IRC that virtio-rng is unable to support fd passing. We attempted: qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom -object rng-random,id=rng0,filename=/dev/fdset/4 -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6 Why are you using th rng-random backend instead of the rng-egd backend? There are two issues with using the egd backend for unprepared devices: 1) The backend spits out \x20\x40 commands(egd blocking entropy request for 0x40 bytes) so it really has to be used with some kind of EGD server implementation otherwise it might feed your /dev/random with predictable bytes if used directly. 2) performance of the egd backend is terrible as I've reported here https://bugzilla.redhat.com/show_bug.cgi?id=915381 (yes I'm aware that I probably should have filed a upstream bug too, but I was hoping Amit would do it in the process) On my machine I managed to do 0.2KiB/s with the egd backend both with using constant data as a high performance source, but also with a true random number generator (in the Raspberry pi SoC, sources 107KiB/s of entropy). The rng-random backend performs a bit better averaging 1.2MiB/s. Peter
Re: [Qemu-devel] virtio-rng and fd passing
Eric Blake ebl...@redhat.com writes: On 03/01/2013 02:08 PM, Anthony Liguori wrote: You can pass chardevs to the egd backend. It's really not a good idea to pass a fd via rng-rangom. Why not? If you are running a single guest, why can't libvirt pass that one guest an fd instead of making qemu open() the file? Why can't QEMU just open(/dev/random)? What's the advantage of libvirt doing the open? Fine, then we won't use fd passing for this device, whatever the reason may be. So let's step back. There are two backends currently supported: rng-random and rng-egd. I don't see any point in taking an fd for rng-random. I don't think labeling comes into play here. But if libvirt wants to interact with virtio-rng in a more intelligent way (implementing a policy to distribute entropy), then rng-egd is the right way to do that. Yes, libvirt will probably use rng-egd when distributing randomness among multiple guests. But libvirt wants to target BOTH forms of rng, in order to let the user choose which one is best for their needs. If rng-random is not useful to any end user, then why did qemu expose it in the first place? And if qemu thought it was worth exposing, then libvirt thinks it is worth targetting, and by using qemu_open instead of raw open, then fd passing is possible. Policy (whether it makes sense to pass an fd for a random generator, and whether /dev/random or /dev/urandom or something else is best) may be important, but it is orthogonal to the issue that I raised about consistency. It seems a bit silly to me for QEMU to never open a file and to reinvent a namespace (via fdsets) to serve that purpose. I understand the reason that fdsets exist (because NFS is stupid and doesn't support labeling). But we aren't doing dynamic labeling of /dev/random and I strongly suspect it's not on NFS anyway. So why are we trying to pass fds here? Regards, Anthony Liguori -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] virtio-rng and fd passing
Peter Krempa pkre...@redhat.com writes: On 03/01/13 21:04, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: Stefan Berger and I discovered on IRC that virtio-rng is unable to support fd passing. We attempted: qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom -object rng-random,id=rng0,filename=/dev/fdset/4 -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6 Why are you using th rng-random backend instead of the rng-egd backend? There are two issues with using the egd backend for unprepared devices: 1) The backend spits out \x20\x40 commands(egd blocking entropy request for 0x40 bytes) so it really has to be used with some kind of EGD server implementation otherwise it might feed your /dev/random with predictable bytes if used directly. Yes. That's the point. 2) performance of the egd backend is terrible as I've reported here https://bugzilla.redhat.com/show_bug.cgi?id=915381 (yes I'm aware that I probably should have filed a upstream bug too, but I was hoping Amit would do it in the process) On my machine I managed to do 0.2KiB/s with the egd backend both with using constant data as a high performance source, but also with a true random number generator (in the Raspberry pi SoC, sources 107KiB/s of entropy). The rng-random backend performs a bit better averaging 1.2MiB/s. That's a bug that I wasn't aware of until you wrote this. I'll look into it next week. Regards, Anthony Liguori Peter
Re: [Qemu-devel] virtio-rng and fd passing
On 03/01/2013 04:05 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 02:08 PM, Anthony Liguori wrote: You can pass chardevs to the egd backend. It's really not a good idea to pass a fd via rng-rangom. Why not? If you are running a single guest, why can't libvirt pass that one guest an fd instead of making qemu open() the file? Why can't QEMU just open(/dev/random)? What's the advantage of libvirt doing the open? sVirt/syscall blacklisting Libvirt WANTS to prohibit qemu from using open()/openat(), and instead get ALL its fds from inheritence across exec() and/or SCM_RIGHTS. In this way, qemu can be made more secure out of the box, even on file systems like NFS that lack SELinux labeling. Right now, if you store your image files on NFS, then you have to explicitly grant SELinux the virt_use_nfs boolean, which says that qemu can open() _any_ file on NFS, even if it is not a file belonging to the guest's disk image. But if we can prohibit qemu from calling open(), while still accessing everything it needs with fd passing, then virt_use_nfs is no longer necessary - and even if the qemu process is compromised by a rogue guest, the compromised process cannot access any file to which it does not already have an fd. But given the way open() blacklisting works, allowing qemu to open(/dev/random) while forbidding open(/nfs/...) is much harder than forbidding all open(). In other words, an all-or-nothing switch is possible only if qemu consistently uses qemu_open() instead of raw open(). I understand the reason that fdsets exist (because NFS is stupid and doesn't support labeling). But we aren't doing dynamic labeling of /dev/random and I strongly suspect it's not on NFS anyway. So why are we trying to pass fds here? Consistency - how do you write a policy that allows open(/dev/random) while forbidding open(/nfs/...)? It's much simpler to forbid open(), even if /dev/random doesn't have any labeling issues. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] virtio-rng and fd passing
Eric Blake ebl...@redhat.com writes: On 03/01/2013 04:05 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 02:08 PM, Anthony Liguori wrote: You can pass chardevs to the egd backend. It's really not a good idea to pass a fd via rng-rangom. Why not? If you are running a single guest, why can't libvirt pass that one guest an fd instead of making qemu open() the file? Why can't QEMU just open(/dev/random)? What's the advantage of libvirt doing the open? sVirt/syscall blacklisting Libvirt WANTS to prohibit qemu from using open()/openat(), and instead get ALL its fds from inheritence across exec() and/or SCM_RIGHTS. In this way, qemu can be made more secure out of the box, even on file systems like NFS that lack SELinux labeling. Opening up files as root and passing the descriptors to an unprivileged process is more secure than doing open() as an unprivileged process. The kernel is capable of doing this enforcement. I don't think it's reasonable to expect QEMU to never use open() at all. Right now, if you store your image files on NFS, then you have to explicitly grant SELinux the virt_use_nfs boolean, which says that qemu can open() _any_ file on NFS, even if it is not a file belonging to the guest's disk image. But if we can prohibit qemu from calling open(), while still accessing everything it needs with fd passing, then virt_use_nfs is no longer necessary - and even if the qemu process is compromised by a rogue guest, the compromised process cannot access any file to which it does not already have an fd. Yes, I understand why this is needed for NFS. But NFS is a corner case of the kernel not being able to do it's job. It doesn't mean we should circumvent the checking the kernel does and reinvent it all again in userspace. But given the way open() blacklisting works, allowing qemu to open(/dev/random) while forbidding open(/nfs/...) is much harder than forbidding all open(). In other words, an all-or-nothing switch is possible only if qemu consistently uses qemu_open() instead of raw open(). I said this when seccomp was first introduced and I'll say it again. blacklisting open() is a bad idea. DAC and MAC already exist and solve this problem. We've got filesystem namespaces too. I understand the reason that fdsets exist (because NFS is stupid and doesn't support labeling). But we aren't doing dynamic labeling of /dev/random and I strongly suspect it's not on NFS anyway. So why are we trying to pass fds here? Consistency - how do you write a policy that allows open(/dev/random) while forbidding open(/nfs/...)? It's much simpler to forbid open(), even if /dev/random doesn't have any labeling issues. I think you're trying to solve the wrong problem (forbidding open()). Regards, Anthony Liguori -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] virtio-rng and fd passing
On 03/01/2013 04:59 PM, Anthony Liguori wrote: I said this when seccomp was first introduced and I'll say it again. blacklisting open() is a bad idea. DAC and MAC already exist and solve this problem. We've got filesystem namespaces too. Let's explore that idea a bit further. What happens if libvirt decides to create a new filesystem namespace for qemu, where libvirt unmounts all non-local filesystems, as well as any file system that does not support SELinux labeling. Then all remaining filesystems, seen by qemu, will enforce SELinux semantics, and we can let qemu open() at will because the open will then be guarded by SELinux. The only remaining access is to files to the unmounted file systems, where fd passing from libvirt bypasses the fact that qemu can't see the file system. I could see that working, and it would still let us get rid of the selinux virt_use_nfs bool while still providing secure NFS out-of-the-box. And your argument is that virtio-rng should be pointed to a character device, never an NFS file, and therefore not using qemu_open() is no real loss because open() will not be blacklisted, just NFS file systems. Okay, maybe that will work. Still, I think I can come up with a scenario where fd passing makes sense. Consider the case of forensic analysis, where a guest image is cloned, and then slight modifications are done on forks of the guest, to play out some what-if scenarios. Let's suppose that I _want_ to have an accurate replay of all inputs to the guest - that means that I capture a fixed chunk of a true random source once, but then on each variation of a guest, I want to replay the _same_ stream of data. Yes, that is not random from the host's perspective - but in forensic analysis, you want to eliminate as many variables as possible. And from the guest's perspective, as long as the data was _originally_ captured from a true random source, replaying the data once per guest won't violate the random expectations within the guest. Now that means that I want to feed virtio-rng with a regular file, not a character device. Now, where do I store that file? Why not store it alongside my disk images - in NFS? That will only work if qemu can access the random data file; in other words, if fd passing is enforced, then accessing a replay stream of previously captured random content from NFS storage requires the use of qemu_open(). Maybe you are right that we don't need to blacklist ALL open(), but the moment we blacklist NFS open() (such as by the alternative of unmounting NFS in the qemu process), then consistency argues that it should still be possible to do fd passing. Should libvirt do fd passing for EVERY file? By your argument, no - only for files living in file systems that were blacklisted. But the point remains - who are you to say that I have no valid business opening a guest but feeding that guest's random hardware from a file that I store on host's NFS? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] virtio-rng and fd passing
On 03/01/2013 06:59 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 04:05 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 02:08 PM, Anthony Liguori wrote: You can pass chardevs to the egd backend. It's really not a good idea to pass a fd via rng-rangom. Why not? If you are running a single guest, why can't libvirt pass that one guest an fd instead of making qemu open() the file? Why can't QEMU just open(/dev/random)? What's the advantage of libvirt doing the open? sVirt/syscall blacklisting Libvirt WANTS to prohibit qemu from using open()/openat(), and instead get ALL its fds from inheritence across exec() and/or SCM_RIGHTS. In this way, qemu can be made more secure out of the box, even on file systems like NFS that lack SELinux labeling. Opening up files as root and passing the descriptors to an unprivileged process is more secure than doing open() as an unprivileged process. The kernel is capable of doing this enforcement. I don't think it's reasonable to expect QEMU to never use open() at all. For blacklisting of open() to succeed we would need to at least pass all file descriptors into QEMU so that QEMU doesn't need to call open() because of the devices it uses. If there are no open() calls left in all/most predictable cases then blacklisting open() could be enabled for those cases (hopefully all of them). Isn't thos the technical aspect to what it comes down to in the end that would let one blacklist open()? Stefan
Re: [Qemu-devel] virtio-rng and fd passing
Eric Blake ebl...@redhat.com writes: On 03/01/2013 04:59 PM, Anthony Liguori wrote: I said this when seccomp was first introduced and I'll say it again. blacklisting open() is a bad idea. DAC and MAC already exist and solve this problem. We've got filesystem namespaces too. Let's explore that idea a bit further. What happens if libvirt decides to create a new filesystem namespace for qemu, where libvirt unmounts all non-local filesystems, as well as any file system that does not support SELinux labeling. Then all remaining filesystems, seen by qemu, will enforce SELinux semantics, and we can let qemu open() at will because the open will then be guarded by SELinux. The only remaining access is to files to the unmounted file systems, where fd passing from libvirt bypasses the fact that qemu can't see the file system. I could see that working, and it would still let us get rid of the selinux virt_use_nfs bool while still providing secure NFS out-of-the-box. And your argument is that virtio-rng should be pointed to a character device, never an NFS file, and therefore not using qemu_open() is no real loss because open() will not be blacklisted, just NFS file systems. Okay, maybe that will work. A simpler version would be to chroot the QEMU process but sure. Still, I think I can come up with a scenario where fd passing makes sense. Consider the case of forensic analysis, where a guest image is cloned, and then slight modifications are done on forks of the guest, to play out some what-if scenarios. Let's suppose that I _want_ to have an accurate replay of all inputs to the guest - that means that I capture a fixed chunk of a true random source once, but then on each variation of a guest, I want to replay the _same_ stream of data. Yes, that is not random from the host's perspective - but in forensic analysis, you want to eliminate as many variables as possible. And from the guest's perspective, as long as the data was _originally_ captured from a true random source, replaying the data once per guest won't violate the random expectations within the guest. Now that means that I want to feed virtio-rng with a regular file, not a character device. Now, where do I store that file? Why not store it alongside my disk images - in NFS? That will only work if qemu can access the random data file; in other words, if fd passing is enforced, then accessing a replay stream of previously captured random content from NFS storage requires the use of qemu_open(). This doesn't work. /dev/random can return partial reads whereas you will likely return full reads. The guest also whitens input from a hardware rng and that involves using additional sources of entropy. Basically, you would need 100% deterministic execution for this to work. There is no valid use-case of rng-random other than using /dev/random. In fact, it was probably a mistake to even allow a filename to be specified because it lets people do silly things (like /dev/urandom). If you want anything other than /dev/random, you should use rng-egd. Regards, Anthony Liguori Maybe you are right that we don't need to blacklist ALL open(), but the moment we blacklist NFS open() (such as by the alternative of unmounting NFS in the qemu process), then consistency argues that it should still be possible to do fd passing. Should libvirt do fd passing for EVERY file? By your argument, no - only for files living in file systems that were blacklisted. But the point remains - who are you to say that I have no valid business opening a guest but feeding that guest's random hardware from a file that I store on host's NFS? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] virtio-rng and fd passing
Stefan Berger stef...@linux.vnet.ibm.com writes: On 03/01/2013 06:59 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 04:05 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 02:08 PM, Anthony Liguori wrote: You can pass chardevs to the egd backend. It's really not a good idea to pass a fd via rng-rangom. Why not? If you are running a single guest, why can't libvirt pass that one guest an fd instead of making qemu open() the file? Why can't QEMU just open(/dev/random)? What's the advantage of libvirt doing the open? sVirt/syscall blacklisting Libvirt WANTS to prohibit qemu from using open()/openat(), and instead get ALL its fds from inheritence across exec() and/or SCM_RIGHTS. In this way, qemu can be made more secure out of the box, even on file systems like NFS that lack SELinux labeling. Opening up files as root and passing the descriptors to an unprivileged process is more secure than doing open() as an unprivileged process. The kernel is capable of doing this enforcement. I don't think it's reasonable to expect QEMU to never use open() at all. For blacklisting of open() to succeed we would need to at least pass all file descriptors into QEMU so that QEMU doesn't need to call open() because of the devices it uses. If there are no open() calls left in all/most predictable cases then blacklisting open() could be enabled for those cases (hopefully all of them). Isn't thos the technical aspect to what it comes down to in the end that would let one blacklist open()? Sandboxing isn't a panacea. The benefit comes from removing unnecessary interfaces from the attack surface. It doesn't help if you blacklist and interface but then invent an RPC that replicates it anyway. Moving the open validation logic from the kernel to libvirt is *not* reducing the attack surface. It's simply moving it from one place (the kernel) to another (libvirt). I'd rather the kernel be the one validating open() calls than libvirt. Regards, Anthony Liguori Stefan
Re: [Qemu-devel] virtio-rng and fd passing
On 03/01/2013 10:17 PM, Anthony Liguori wrote: Stefan Berger stef...@linux.vnet.ibm.com writes: On 03/01/2013 06:59 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 04:05 PM, Anthony Liguori wrote: Eric Blake ebl...@redhat.com writes: On 03/01/2013 02:08 PM, Anthony Liguori wrote: You can pass chardevs to the egd backend. It's really not a good idea to pass a fd via rng-rangom. Why not? If you are running a single guest, why can't libvirt pass that one guest an fd instead of making qemu open() the file? Why can't QEMU just open(/dev/random)? What's the advantage of libvirt doing the open? sVirt/syscall blacklisting Libvirt WANTS to prohibit qemu from using open()/openat(), and instead get ALL its fds from inheritence across exec() and/or SCM_RIGHTS. In this way, qemu can be made more secure out of the box, even on file systems like NFS that lack SELinux labeling. Opening up files as root and passing the descriptors to an unprivileged process is more secure than doing open() as an unprivileged process. The kernel is capable of doing this enforcement. I don't think it's reasonable to expect QEMU to never use open() at all. For blacklisting of open() to succeed we would need to at least pass all file descriptors into QEMU so that QEMU doesn't need to call open() because of the devices it uses. If there are no open() calls left in all/most predictable cases then blacklisting open() could be enabled for those cases (hopefully all of them). Isn't thos the technical aspect to what it comes down to in the end that would let one blacklist open()? Sandboxing isn't a panacea. The benefit comes from removing unnecessary interfaces from the attack surface. It doesn't help if you blacklist and interface but then invent an RPC that replicates it anyway. Moving the open validation logic from the kernel to libvirt is *not* reducing the attack surface. It's simply moving it from one place (the kernel) to another (libvirt). It depends on what one defends against. If a jail-break succeeds and open() is disabled, then that attack surfaces was effectively reduced. It's hard to say whether opening files within libvirt could then allow new exploits. Stefan
[Qemu-devel] virtio-rng and fd passing
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
-object rng-random,id=rng0,filename=/dev/fdset/4 -device
virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6
qemu-system-x86_64: -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6:
Could not open '/dev/fdset/4'
Looks like this code is the culprit, in backends/rng-random.c:
static void rng_random_opened(RngBackend *b, Error **errp)
{
RndRandom *s = RNG_RANDOM(b);
if (s-filename == NULL) {
error_set(errp, QERR_INVALID_PARAMETER_VALUE,
filename, a valid filename);
} else {
s-fd = open(s-filename, O_RDONLY | O_NONBLOCK);
For fd passing to work, we have to use qemu_open() instead of raw
open(). Is there any way to enforce that all files being opened by qemu
go through the appropriate qemu_open() wrapper?
Meanwhile, we have a quandary on the libvirt side of things: qemu 1.4
supports fd passing in general, but does not support it for rng. I
guess the same is true for -blockdev - we don't (yet) have a way to do
fd passing for backing files. Do we need some sort of QMP command that
will let libvirt query for a particular device whether that device is
known to support fd passing, so that libvirt can use fd passing for all
supported devices, while falling back to older direct open()s, and to
know which instance of qemu can safely have open() blocked at the
SELinux or syscall blacklist level?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] virtio-rng
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jamie Lokier wrote: Ian Molton wrote: With VMs, in some circumstances it might be preferable to trust the host when it says it's providing already-tested entropy. After all the host has total control over the guest anyway, and the host entropy has already been run through the same checks. I dont know. The guests might not necessarily trust the host. I can certainly see some benefit of not running the checks twice, however, and this applies to some other hw rng drivers too - One in particular I know will shut down if it detects that its entropy source(s) have gone bad. So I think virtio-rng could benefit form being a special case, if the host says I assert this is entropy, you might inject it directly, and thus work even with guests that aren't running the rngd daemon for one reason or another. (E.g. embedded system guests.) I wonder if a 'rngd-lite' might not be an easier solution. I cant imagine theres going to be much performance hit. That said, even on my full-fat x86-64 box here, rngd weighs in at just 32KB and only needs libc... I still intend to submit my virtio-rng driver, if thats what you mean, since it presents the data via the same routes as all the other hw rng sources. I feel this approach has value. Suddenly I'm intrigued by this intend to submit as I see a virtio-rng driver already in the 2.6 tree... What have I misunderstood? host side driver for qemu... I guess the proper term is qdev ? - -Ian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLAmphAAoJEFIjE1w7L6YHm5cP/0jotxofq3OUTaPtqUHGTw8K PJ8sfkcNvJ/4GSEbCYCXcRsSqnG32R+w6LF8lOInWsi3BJsNUqRBgInGnDzC8/kV 1vkhRQELUBgNlLes+pG6GoaQZSVnQ8Z6HbNYSxyyZ+DqESR2+f0Gm8j+QdyTpXxS ARVoDGOM+IduZL//NMy4+hBPUGymosGKepVmaT/9cVPubGumq/f+mf21AdwCPEvk JIlRV1asqbBU7jyut5uVULpXwqygc6+kkZl6IzIPdv9BbcI9KersikL9srXZHJa9 JtyTjXdE9lsogkJkWD5Y9yL0o9oBuQdAKD8WeN+v//imzhbcuQ5kASiGMSkRo4eD yi8oP8PIN+vhI6MhLKML7B6n4Li+xDegNxgH1qSeB3IxovTUwuVoyK7C3GIw9Kt8 h/B6FQ0gE7yNtqsFMz4m2+vWdN9ZkNPX3o5bv5DDbPiKfVUZYu0wuwCcvtD3Wbq5 SMf1rxHCgRx3B526bJGWpgeataztp1B1B2+ml2Mdbgb2r35QOaTw/ENpt4n68o/z ITzOAOLlPHkUDLlurkQ8jMX7rT9W/NlL/y60jImjgv5zxqggEkmMlQqSnUKwIXRE CAZAq9+6eQ/vf6r/rY8GlVVfKr5L8tRovNSbX35vbKkjpvf+aWDr66ON+bDh2Mn+ Z5LmO4HSRe/2M7e4D8HV =9LtM -END PGP SIGNATURE-
Re: [Qemu-devel] virtio-rng
On (Mon) Nov 16 2009 [17:58:22], Ian Molton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerd Hoffmann wrote: Maybe ... -chardev socket,id=egd,host=egd.domain.tld,port=whatever -device virtio-rng,chardev=egd I've had a go at modifying virtio-console.c to use these semantics, attached below. I'd appreciate it if you could let me know if this is 'the right way'. I'm doing that as part of revamping of the virtio-console driver. You can see the latest patch I sent out here: http://patchwork.ozlabs.org/patch/36901/ Amit
Re: [Qemu-devel] virtio-rng
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Amit Shah wrote: (Any reason to take this off-list?) None other than hitting reply rather than reply-all. CCing list once more :-) Either way, you still need to specify the properties - they've just moved into the console driver in your patch by the look of it. Yeah; there are two ways of setting properties -- from the command line or from code. What you're doing is something like -virtiorng,a=foo,b=bar Ah, I see why we're at cross purposes here - I thought we'd moved to discussing virtio-console. I've already moved to qdev based init for virtio-rng - 'fixing' virtio-console was where I learnt about the 'new way' (qdev). I'd prefer to do the same for virtio-rng, Here I refer to you having (and I didnt apply the patch so I may have misread) dropped the virtio-pci proxy from virtio-console. Once I've got a tree I can apply your patch to I'll take another look :-) You should work on the qemu.git tree (use -enable-kvm for testing :). KVM will get the changes automatically when your changes get merged in qemu and the kvm maintainers next merge the qemu git repo. I'll do that then ;-) Yes, I saw that. Would it not be better to generate the device / chardev pair dynamically though, rather than preserve the icky old array? I don't understand what you mean by 'dynamically'. Rather than have that array virtcon_hds at all, create the pairs of host side data and qdev properties during parsing the commandline - no need to store them up and iterate through the later, or to set an arbitrary limit on how many can be specified in that way. Might be an idea for qemu to warn people that this syntax will be deprecated, too... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLAoSmAAoJEFIjE1w7L6YHcq4P/jlzcNvWHqqkRQkdQWsy6JUh Kh3LDh23nuK9u+aoFgXP8gpej8jT6+cAdzQ+opk/JnPQXDW4nSWcdN5HKPAmTKMP +N78mx7w0WAOFPXd33ZRvP9mqIir6wPmwibC1aUyk6Q6+KH9Io+IDvH6qfrkIung mYHL3WSDObkcHa6+F1ADxYA9TWr9eib6lOu8EG4LgSeJRq48+2b++kvhd8mFcMdg yu1ed7V0U43rMhbIrAtlQsp3BWlF3KdrciFtlXyLJ9iBeSp8H0IUn+XWt1nqvNdP T47J6Weiv7wap2RqSj7Pf5xFs45zyw2ismsfmR9iMraanISF+laZSoBynT/Et7eg d8BoEE/PGsYeFcRm1cpETPkO7fRQxXmd8To6IqomWmT0r41KcEW9Bcs7/MIZcPpo LtH3jZqbsd5vLEIf769rs3g38gmkNpq3sfDMJ+a5xRW9qdVOmeWfD4bPpqwIPYrq MRF/YSZch+aLsKx7Ql+CxM+r/xY7HscIS/4hfIC8OzKnEOxO+jGiV4Mf9RMfOBZw DdXv9YKeu3gemhguKo4NEoTonmvcv6PvhVplu5T4+wJCMjI0T2QkaJmNQFqQSfQj FB+Qri0ad8GY5H6eirvXq/6qBHtuMP+9fJn0A/ErvlXTBKYJg+VeBQSraSylOy4c ii9UNqk7klAw4lN7hnuP =af4Q -END PGP SIGNATURE-
Re: [Qemu-devel] virtio-rng
On (Tue) Nov 17 2009 [11:10:32], Ian Molton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Amit Shah wrote: (Any reason to take this off-list?) None other than hitting reply rather than reply-all. CCing list once more :-) Either way, you still need to specify the properties - they've just moved into the console driver in your patch by the look of it. Yeah; there are two ways of setting properties -- from the command line or from code. What you're doing is something like -virtiorng,a=foo,b=bar Ah, I see why we're at cross purposes here - I thought we'd moved to discussing virtio-console. I've already moved to qdev based init for virtio-rng - 'fixing' virtio-console was where I learnt about the 'new way' (qdev). I actually meant to talk about virtio-console but had the virtio-rng example ready in mind. I thought you did the same thing for console too? Sorry I've not really looked at the patch in detail so you can disregard that comment. I'd prefer to do the same for virtio-rng, Here I refer to you having (and I didnt apply the patch so I may have misread) dropped the virtio-pci proxy from virtio-console. Once I've got a tree I can apply your patch to I'll take another look :-) It slightly works differently now: virtio is supposed to be pci-agnostic. So what now happens is: virtio-console hooks on to the virtio-serial-bus via -device virtconsole virtio-serial-bus hooks on to the virtio-pci-proxy via -device virtio-serial-pci Yes, I saw that. Would it not be better to generate the device / chardev pair dynamically though, rather than preserve the icky old array? I don't understand what you mean by 'dynamically'. Rather than have that array virtcon_hds at all, create the pairs of host side data and qdev properties during parsing the commandline - no need to store them up and iterate through the later, or to set an arbitrary limit on how many can be specified in that way. qdev won't understand the old-style commandline syntax; so once -virtioconsole is encounters, all parsing of the arguments for that param are to be done by the code that handles -virtioconsole. The array is maintained because multiple virtio-consoles could be spawned, upto a max. of MAX_VIRTIO_CONSOLES. But, as it stands, MAX_VIRTIO_CONSOLES is 1 and so the array can be dropped, but a local var. would still be needed to fetch the chardev and then init it properly using qemu_opt. Might be an idea for qemu to warn people that this syntax will be deprecated, too... Yes, that should be done (maybe for 1-2 releases). Amit
Re: [Qemu-devel] virtio-rng
Hi, in qdev_init_chardev() the return value is picked based upon the name of the device. For now, I've added a third 'if clause' to match for my driver and pass through the CharDriverState * fron vl.c for my rng driver, however I'd like to solve this properly. Ignore qdev_init_chardev() ... I think a simple name-pointer type matching system would work fine, however I'd like to know if anyone else has sorted this yet, or if I should be doing things differently altogether. Use a chardev property (look at serial.c, isa-serial device). Then you'll configure it on the qemu command line like this: -chardev $backend,id=some-name-here,more-chardev-parameters -device virtio-rng,chardev=some-name-here HTH, Gerd
Re: [Qemu-devel] virtio-rng
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerd Hoffmann wrote:
Hi,
Hi!
Thanks for your reply - I should have posted to say I'd partially solved
this. I have a question though,
Use a chardev property (look at serial.c, isa-serial device).
Then you'll configure it on the qemu command line like this:
-chardev $backend,id=some-name-here,more-chardev-parameters
-device virtio-rng,chardev=some-name-here
I've done something similar (below)
My commandline looks like:
- -virtiorng dev=/dev/foo,rate=1234
I added some properties to my driver which are obviously then filled in
from the options code, and I do my init like this:
VirtIODevice *virtio_rng_init(DeviceState *dev, RNGConf *rngdev)
{
VirtIORng *s;
s = (VirtIORng *)virtio_common_init(virtio-rng,
VIRTIO_ID_RNG,
0, sizeof(VirtIORng));
if (!s)
return NULL;
s-vdev.get_features = virtio_rng_get_features;
s-vq = virtio_add_queue(s-vdev, 128, virtio_rng_handle);
s-chr = qemu_chr_open(vrngdev, rngdev-device, NULL);
...
return s-vdev;
}
Is this 'not the right way' ? I think the commandline looks much simpler
this way.
OTOH, I can see that this might help with my next problem, which is that
I want to write EGD support for virtio-rng, so I'm guessing my
commandline would (in your scheme) need to be something like:
-tcpsocketthing $addr.of.egd.server,id=some-name-here,
more-egd-client-options
-device virtio-rng,tcpsocketthing=some-name-here,rate=$limit
I guess the idea here is to seperate the host related config from the
guest OS setup ?
This doesnt, however, get around my problem that the -device option
doesnt know how to parse OPT_SIZE types, though. (I'd like to be able to
specify 'rate' in B/s or KB/s (or even kbits/sec, more appropriately))
- -Ian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJLAUWCAAoJEFIjE1w7L6YHi7YP/1JXi1T1T3/GUG8o+ZTXJbV5
KUCkwZct7bAqMaZyxsbkbqo947tNjL006kupvUwRsfS/Hrp2uf9K/+o0tTGr87Kl
ec7sWAU67q1ydhFQQYcAnUeBEe2qO9qIXC2d32QOPOTBftwmmCYMSRob+VG0jOvy
eBN9ZdnUM+vGWmFfAxH8U1Wcx4sxEni+QZ36cFSCwAVfimxqkj9h2sI4yYVmIwWI
3VN6BERQgBGMp81fRY+QiVFGSXEPfLi/ppI8Ta6MOO3dB91XzsqDcMNIHIJwmxFz
S2uSMl9py3P5jGb2hhHHO56Fvl8paBOEvVm1SsOMXID9MpnrSHJZmlnKAe+P0nY2
EX+pvvqJZwA2OS15fjzypmho0WZtvS/HdrvEp9SQcM6dgfyVapR6H/GLrqV1iEZ5
uarKBbFKuWVCl8rWc4dZm6sMDfIuzjUgeMZyEhUx3dHVpzzd1B0zIZOVFyI7Fde1
+ox+lvm4EXBV/hji4GCc3E1pJSlmQtokSSTuaVrAXrwJRJcZpX3cjsQad5S5OOrI
zXYgs2H/ITINxnVjxkPTHty1txcZrs2Wvjbs8LvkE7LsZuquy+maVN2VS7ahwy3q
qCAkfm8Yp1QVmPM1sAlhuMPCrtQKl4VAt825PbpjEd4DNHZb1hnK8s7dc3NpVKcv
NK+vr3fUldUlsU+6Om0r
=yNv7
-END PGP SIGNATURE-
Re: [Qemu-devel] virtio-rng
On 11/16/09 13:28, Ian Molton wrote:
I've done something similar (below)
My commandline looks like:
- -virtiorng dev=/dev/foo,rate=1234
I added some properties to my driver which are obviously then filled in
from the options code, and I do my init like this:
There is no need for a new -virtiorng switch. qdev allows to set any
property when creating devices via -device on the command line.
VirtIODevice *virtio_rng_init(DeviceState *dev, RNGConf *rngdev)
{
VirtIORng *s;
s = (VirtIORng *)virtio_common_init(virtio-rng,
VIRTIO_ID_RNG,
0, sizeof(VirtIORng));
if (!s)
return NULL;
s-vdev.get_features = virtio_rng_get_features;
s-vq = virtio_add_queue(s-vdev, 128, virtio_rng_handle);
s-chr = qemu_chr_open(vrngdev, rngdev-device, NULL);
...
returns-vdev;
}
Is this 'not the right way' ? I think the commandline looks much simpler
this way.
The point is to separate host and guest state. -chardev ist host state,
the device is guest state, and they are linked using the chardev name.
OTOH, I can see that this might help with my next problem, which is that
I want to write EGD support for virtio-rng, so I'm guessing my
commandline would (in your scheme) need to be something like:
-tcpsocketthing $addr.of.egd.server,id=some-name-here,
more-egd-client-options
-device virtio-rng,tcpsocketthing=some-name-here,rate=$limit
Maybe ...
-chardev socket,id=egd,host=egd.domain.tld,port=whatever
-device virtio-rng,chardev=egd
... ?
This doesnt, however, get around my problem that the -device option
doesnt know how to parse OPT_SIZE types, though. (I'd like to be able to
specify 'rate' in B/s or KB/s (or even kbits/sec, more appropriately))
Yes, there is no qdev property type (yet) which can parse those
postfixes. Which is no reason to not add one though ;)
cheers,
Gerd
Re: [Qemu-devel] virtio-rng
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerd Hoffmann wrote:
Maybe ...
-chardev socket,id=egd,host=egd.domain.tld,port=whatever
-device virtio-rng,chardev=egd
I've had a go at modifying virtio-console.c to use these semantics,
attached below. I'd appreciate it if you could let me know if this is
'the right way'.
This doesnt, however, get around my problem that the -device option
doesnt know how to parse OPT_SIZE types, though. (I'd like to be able to
specify 'rate' in B/s or KB/s (or even kbits/sec, more appropriately))
Yes, there is no qdev property type (yet) which can parse those
postfixes. Which is no reason to not add one though ;)
I'll look into it ;-)
Heres my patch to virtio-console. The device is now specified like this:
- -chardev file,path=/path/to/testfile,id=test
- -device virtio-console-pci,chardev=test
(for example)
TTFN!
- -Ian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJLAZK2AAoJEFIjE1w7L6YHS0UP/0v/0a42Mon+SsUfowv7EpKw
0clLC/JCTcNFzSD1PqFdYV5E2kqCeMHHRS2DsCjjGFxgC5uOD7tuBLp66dk2vxvh
0QnIXkVD9FRBfRS5E2VtjterYmp2Fu+EBE3ugtAiKZhtQWVtmiQfRVqrqClpz8hd
4l/RXxTNkjJE5yRm9J7tBZ9lZqJ5tKTxqQtQV2+pPghOX7zAu4tsv3kLk9LY6SZr
dfUfv1iXiNwiZh3Z7pKEiezzJKtoPS5y30wIszPziv2Ef/V153hxED35nT6y1+1i
16wknBJgFUG7Hp0GrprUp6N5pRTX2f7X07IXhPdMyX79J9RtS8Vg7+5aX6nsK5m0
8B0WvXZqn6i+DHGrcXNPw0IpkP/MDCTVSn15O9TsiyKLnkKfjHlQHzhDkVb9yMub
bkd4uE8e9i+vqIY57kqsvcfGytcw4g3bHzT2SasKKyBjGVcwahQT4zDI9PjX7CUg
vxqktTy3y4de/ijrzuIy5e/oCK6b9AAKI0dJJJfH6NsP1ljMldEeJlkLKRheWBy9
2AqdkmQhD3eD5fo5idmp9oxx0okfg/p3v5IdLTUadgIYSL70J61fb0TL6hBNo8TS
uuCoZdgeKXD470tUXWvrWPxIACvG8ZAMYhz3CGXrFGb8WJjt1Rb0DXvHbr2Z8Wdn
2PwPSOliAY0iPfzo79Ke
=TM+C
-END PGP SIGNATURE-
From 40a7a43484176194490a7980741a6d4764c10fb1 Mon Sep 17 00:00:00 2001
From: Ian Molton ian.mol...@collabora.co.uk
Date: Mon, 16 Nov 2009 17:49:18 +
Subject: [PATCH] virtio-console: Remove ugly device reg. hack
This patch removes the unsightly hack in qdev_init_chardev() that
was used in order to pass the host device to virtio-console.
It does not remove the limit of only one console which is imposed by
the use of the virtio-pci proxy in virtio-pci.c, however if this were fixed,
it would be possible to register numerous consoles without further modification
of the virtio-console qdev.
Signed-off-by: Ian Molton ian.mol...@collabora.co.uk
---
hw/pc.c |9 -
hw/ppc440_bamboo.c |7 ---
hw/qdev.c |9 ++---
hw/virtio-console.c |8
sysemu.h|6 --
vl.c| 37 -
6 files changed, 6 insertions(+), 70 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index fb73a54..1d0c870 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -1368,15 +1368,6 @@ static void pc_init1(ram_addr_t ram_size,
extboot_init(info-bdrv, 1);
}
-/* Add virtio console devices */
-if (pci_enabled) {
-for(i = 0; i MAX_VIRTIO_CONSOLES; i++) {
-if (virtcon_hds[i]) {
-pci_create_simple(pci_bus, -1, virtio-console-pci);
-}
-}
-}
-
#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
if (kvm_enabled()) {
add_assigned_devices(pci_bus, assigned_devices, assigned_devices_index);
diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
index 25417e3..c94c961 100644
--- a/hw/ppc440_bamboo.c
+++ b/hw/ppc440_bamboo.c
@@ -109,13 +109,6 @@ static void bamboo_init(ram_addr_t ram_size,
env = ppc440ep_init(ram_size, pcibus, pci_irq_nrs, 1, cpu_model);
if (pcibus) {
-/* Add virtio console devices */
-for(i = 0; i MAX_VIRTIO_CONSOLES; i++) {
-if (virtcon_hds[i]) {
-pci_create_simple(pcibus, -1, virtio-console-pci);
-}
-}
-
/* Register network interfaces. */
for (i = 0; i nb_nics; i++) {
/* There are no PCI NICs on the Bamboo board, but there are
diff --git a/hw/qdev.c b/hw/qdev.c
index 373ddfc..237da57 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -321,13 +321,8 @@ void qdev_machine_creation_done(void)
CharDriverState *qdev_init_chardev(DeviceState *dev)
{
static int next_serial;
-static int next_virtconsole;
-/* FIXME: This is a nasty hack that needs to go away. */
-if (strncmp(dev-info-name, virtio, 6) == 0) {
-return virtcon_hds[next_virtconsole++];
-} else {
-return serial_hds[next_serial++];
-}
+
+return serial_hds[next_serial++];
}
BusState *qdev_get_parent_bus(DeviceState *dev)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index bc3681f..8fe8a5d 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -21,7 +21,7 @@ typedef struct VirtIOConsole
{
VirtIODevice vdev;
VirtQueue *ivq, *ovq;
-CharDriverState *chr;
+CharDriverState chr;
} VirtIOConsole;
static VirtIOConsole *to_virtio_console(VirtIODevice *vdev)
@@ -39,7 +39,7
Re: [Qemu-devel] virtio-rng
Ian Molton wrote: Heres my patch to virtio-console. The device is now specified like this: - -chardev file,path=/path/to/testfile,id=test - -device virtio-console-pci,chardev=test It'd be nice if some options on the qemu command line (or config file) resulted in the guest kernel getting entropy (assuming a kernel with the appropriate support), without having to run a special entropy-injection daemon in the guest. virtio-console can be used for that, but it'd be necessary to have a way to tell the guest kernel to treat that particular device as an entropy source. Even just a standard name. -- Jamie
Re: [Qemu-devel] virtio-rng
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jamie Lokier wrote: Ian Molton wrote: Heres my patch to virtio-console. The device is now specified like this: - -chardev file,path=/path/to/testfile,id=test - -device virtio-console-pci,chardev=test Note, I think the patch above is broken and slipped by me because I forgot to make clean - I'll doublecheck tomorrow. It'd be nice if some options on the qemu command line (or config file) resulted in the guest kernel getting entropy (assuming a kernel with the appropriate support), without having to run a special entropy-injection daemon in the guest. How, though - AFAIK linux has no drivers specifically intended to feed entropy into the kernels pool - all the hwrng drivers use a userspace tool to do so. I still intend to submit my virtio-rng driver, if thats what you mean, since it presents the data via the same routes as all the other hw rng sources. I feel this approach has value. - -Ian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLAd1fAAoJEFIjE1w7L6YHqk4QAKSUMZ9VUJss4YWecDPS52DF Jc7sbDEDuk6bRziRqY8nYMovOzalXgbcfSR3ElhZ4lAEGAGwDP1Qa9IbLh1vf083 UgLZa6FRSWbf5A72+Jl3vLzFnzraWp7Y3m6/qX4mv+NHyBRrBGJ5RwJ7DCTeW8I0 9YScryKZiwPdH2CW+ZUj1+mdbbX/n28mJzUHByRkUgLmKHEXgjNdSRBgtM8/YTia yEO2arQC0Oq+t+r/cjy0B5HTg2Qq+mqFIr9gTIIN8xuVmEuX2mNoT5BSJwGoOWYS +tjTusCXQ/SF1FgGBmNaFddtUTLge1op1gKtGEwsX8QqYmLCo9TBhDzfVZB+U+jM m5ACEHYFCAuYQWOMsajcO78wy6q5yKFE1MJrP69EGR9wtGHNeXVsRQ0EGTqH+rs2 m66+Y0sqzvRvaYqUHSvZMNUf1FWEapkwDLYfJ87twdL1OIqOA5knBMrmZO+rF6bK RKXGeNK/sTnvL0OEXkzeeaw8Em7ykeyVJi9rO9J8XIKH6cE/XC1ab7uNyFrSIGS6 ELvhbrzJ/c5vp/mZQOaMYrj+1+2QAv+0DpF4DDpQOuiuXFR4O6vh+Tz/qjoFxgzF Dkh4ggPmbbRWjYS0XNa0p6zvlLC+cKXKnkrOnsxcbre9CQsl4fgMtoAIqApNdlmB HNoo62fsogVUHaJyJVu7 =eD2D -END PGP SIGNATURE-
Re: [Qemu-devel] virtio-rng
Ian Molton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jamie Lokier wrote: Ian Molton wrote: Heres my patch to virtio-console. The device is now specified like this: - -chardev file,path=/path/to/testfile,id=test - -device virtio-console-pci,chardev=test Note, I think the patch above is broken and slipped by me because I forgot to make clean - I'll doublecheck tomorrow. It'd be nice if some options on the qemu command line (or config file) resulted in the guest kernel getting entropy (assuming a kernel with the appropriate support), without having to run a special entropy-injection daemon in the guest. How, though - AFAIK linux has no drivers specifically intended to feed entropy into the kernels pool - all the hwrng drivers use a userspace tool to do so. You're right, with the reason being hardware randomness should be tested before being passed back to the kernel as trusted entropy, as it might not be functioning properly or might not have the quality it claims to have. With VMs, in some circumstances it might be preferable to trust the host when it says it's providing already-tested entropy. After all the host has total control over the guest anyway, and the host entropy has already been run through the same checks. So I think virtio-rng could benefit form being a special case, if the host says I assert this is entropy, you might inject it directly, and thus work even with guests that aren't running the rngd daemon for one reason or another. (E.g. embedded system guests.) I still intend to submit my virtio-rng driver, if thats what you mean, since it presents the data via the same routes as all the other hw rng sources. I feel this approach has value. Suddenly I'm intrigued by this intend to submit as I see a virtio-rng driver already in the 2.6 tree... What have I misunderstood? Thanks, -- Jamie
[Qemu-devel] virtio-rng
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, I'm writing a virtio-rng host-side driver for qemu-kvm, and I've got something up and running that works, and will pass data gathered from a char device on the host through to the virtio-rng driver on a guest copy of linux. Ultimately it'll get its entropy from egd as well, but for now I'd like to solve the issue in hw/qdev.c. in qdev_init_chardev() the return value is picked based upon the name of the device. For now, I've added a third 'if clause' to match for my driver and pass through the CharDriverState * fron vl.c for my rng driver, however I'd like to solve this properly. I think a simple name-pointer type matching system would work fine, however I'd like to know if anyone else has sorted this yet, or if I should be doing things differently altogether. also, what does '_hds' stand for? eg. 'virtcon_hds'[] Thanks, - -Ian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJK+y1LAAoJEFIjE1w7L6YHlI4P/i4QPbsIASmCLtI9RiEtF7LF NguXv+HCNme8MK6bQpHKLYIJ1q/DSImeeJPjqe/PF1unOBP0d4GmsC+qnLGj4CZn LCRiqf+ZgVPI/fX8TQ8TOzN9o31EOnWmxOKuj+zDDhbRxG/mY2OzOQCLEBkQ26GL Pru981FBVJiEPP2JnWnR6Hn+IZaazcyo+ychk0UhQYasmv8XTC75DiiProhyXFJk TXa8UN+lWd1U1a0mmmg1gxttQrYZiC5i4+k609HY8v3poZ0kjmlH0hIUHt+3FHE8 pA1WL/B26EhNem3ZazGGJ8sNdGg60VTjEBSHyGveCdUtiQU2TWWESBOesQoALkoE 8mONeytgsv7GZ9sh0a1RTInvSsA2TyV/hzQphOtTl6SNEETlGEsFNJpLk+6GeO89 g5A3vdgsOL18ymWxDTf/Ts14mK4+QMa9x4T2Cpttip1LuOwDoV/PCKfpg1q9TT+d C04TFR7qgl6eAsErHhHlFYmWNcMHn00t9jOEBUTMjIi5xKwsCr+ktWxF0yxLQdlu co7gLZd4ck4N8GMltPjIXGMnqWLsemf4b7Gpg8wtIjmK5f7l58qVZW0Qsdx9ujJc MLxQwKvk5OdE+uGMBUDynAGW926Fu/QhdrAhWSbzDFrIjysTY6fzXgNaQa+8HoL9 5fB9UiotqwfYy95HnZV9 =ABHJ -END PGP SIGNATURE-
Re: [Qemu-devel] virtio-rng
I'm writing a virtio-rng host-side driver for qemu-kvm, and I've got something up and running that works, and will pass data gathered from a char device on the host through to the virtio-rng driver on a guest copy of linux. Why do you need a special device? Isn't a regular serial data stream (i.e. multiport virtio-console) sufficient? You can then connect that to your source of random data (e.g. /dev/random) without requiring any changes to qemu. Paul
