Re: [Qemu-devel] virtio-rng and fd passing

Re: [Qemu-devel] virtio-rng and fd passing

[Paolo Bonzini]

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

[H. Peter Anvin]

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

[Anthony Liguori]

Eric Blake <eblake@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

[Stefan Berger]

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

[H. Peter Anvin]

The guest kernel already provides the PRNG itself.  We have been over this...

Stefan Berger <stefanb@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

[Stefan Berger]

On 03/01/2013 03:04 PM, Anthony Liguori wrote:
> Eric Blake <eblake@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

[Paolo Bonzini]

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

[Anthony Liguori]

Stefan Berger <stefanb@linux.vnet.ibm.com> writes:

> On 03/01/2013 03:04 PM, Anthony Liguori wrote:
>> Eric Blake <eblake@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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] virtio-rng and fd passing

[Peter Krempa]

On 03/01/13 21:04, Anthony Liguori wrote:
> Eric Blake <eblake@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

[Anthony Liguori]

Eric Blake <eblake@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

[Anthony Liguori]

Peter Krempa <pkrempa@redhat.com> writes:

> On 03/01/13 21:04, Anthony Liguori wrote:
>> Eric Blake <eblake@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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

On 03/01/2013 04:05 PM, Anthony Liguori wrote:
> Eric Blake <eblake@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] virtio-rng and fd passing

[Anthony Liguori]

Eric Blake <eblake@redhat.com> writes:

> On 03/01/2013 04:05 PM, Anthony Liguori wrote:
>> Eric Blake <eblake@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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 3113 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] virtio-rng and fd passing

[Stefan Berger]

On 03/01/2013 06:59 PM, Anthony Liguori wrote:
> Eric Blake <eblake@redhat.com> writes:
>
>> On 03/01/2013 04:05 PM, Anthony Liguori wrote:
>>> Eric Blake <eblake@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

[Anthony Liguori]

Eric Blake <eblake@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

[Anthony Liguori]

Stefan Berger <stefanb@linux.vnet.ibm.com> writes:

> On 03/01/2013 06:59 PM, Anthony Liguori wrote:
>> Eric Blake <eblake@redhat.com> writes:
>>
>>> On 03/01/2013 04:05 PM, Anthony Liguori wrote:
>>>> Eric Blake <eblake@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

[Stefan Berger]

On 03/01/2013 10:17 PM, Anthony Liguori wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 03/01/2013 06:59 PM, Anthony Liguori wrote:
>>> Eric Blake <eblake@redhat.com> writes:
>>>
>>>> On 03/01/2013 04:05 PM, Anthony Liguori wrote:
>>>>> Eric Blake <eblake@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

Re: [Qemu-devel] virtio-rng and fd passing

[Paolo Bonzini]

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

[Anthony Liguori]

Paolo Bonzini <pbonzini@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

[Anthony Liguori]

Stefan Berger <stefanb@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

[Amit Shah]

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

[Daniel P. Berrange]

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

[Corey Bryant]

On 03/01/2013 10:34 PM, Stefan Berger wrote:
> On 03/01/2013 10:17 PM, Anthony Liguori wrote:
>> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>>
>>> On 03/01/2013 06:59 PM, Anthony Liguori wrote:
>>>> Eric Blake <eblake@redhat.com> writes:
>>>>
>>>>> On 03/01/2013 04:05 PM, Anthony Liguori wrote:
>>>>>> Eric Blake <eblake@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

[Corey Bryant]

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

On 03/01/2013 08:13 PM, Anthony Liguori wrote:
> Eric Blake <eblake@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] virtio-rng and fd passing

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

[adding libvirt]

On 03/03/2013 02:05 PM, Anthony Liguori wrote:
> Paolo Bonzini <pbonzini@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] virtio-rng and fd passing

[Anthony Liguori]

Eric Blake <eblake@redhat.com> writes:

> [adding libvirt]
>
> On 03/03/2013 02:05 PM, Anthony Liguori wrote:
>> Paolo Bonzini <pbonzini@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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] virtio-rng and fd passing

[H. Peter Anvin]

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

[Amit Shah]

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