[libvirt] Add support for QEMU file descriptor sets

[Eric Blake]

On 01/26/2013 09:17 PM, Stefan Berger wrote:
>> In a subsequent patch we now test inside that function whether the new
>> command line parameter is available using the capability (from another
>> patch) and create fd=/dev/set/10 and vhostfd=/dev/set/20 respectively
>> *and* already add "-add-fd set=10,fd=21" and "-add-fd set=20,fd=23" to
>> virCommand using the functions I already posted (as the lowest layer).
>>
>> Would it be that simple, or do we need to add more parameters to
>> -add-fd set=10,fd=21,xyz under certain circumstances?

Ideally, we'd also want to use the opaque parameter of each -add-fd
call, so that when we later use QMP commands to query what fdsets exist,
the opaque parameter can tell us what filenames we passed in (it makes
bookkeeping easier if you know that fd 5 was tied to /dev/tpm, compared
to just knowing that it is an open fd but not what it came from).

Then, if I remember right, qemu's add-fd commands are set up so that
every time code in qemu calls qemu_open(), it dup's the original fd; so
even if we use -add-fd on the command line, qemu doesn't directly read()
and write() the fd we passed, but its own copy.  Depending on the type
of fd (such as passing the write end of a pipe, where libvirt keeps the
read end, but the read end won't see an EOF until _all_ copies of the
write end have been closed), that means we need to tell qemu to close
the original once all copies are in place.  So even if we don't need to
support hotplug right away, we _do_ need to support at least the
remove-fd QMP command after 'qemu -S -add-fd...' has exec'd, but before
issuing the 'cont' QMP command to run the guest.

> 
> Ok, so likely this was a bad example and fd= does not need to be
> replaced with the fd sets. There are five occurrences of path= in the
> code, which could be handled similarly as described above with an
> additional open() and virCommandTransferFD(). My guess is that you want
> to eliminate the syscall open() usage within QEMU. Is that right ?

Yes, at least one end goal of using -add-fd on the command line (and
'add-fd' over the monitor during hotplug) is that we can use SELinux to
prevent qemu from calling any open().  This in turn means that qemu can
use _only_ file descriptors that have been handed in by the management
app, and are therefore securely labeled.  This comes into play when
using NFS: there is no way to apply SELinux labels to NFS files (well,
NFS 4 might eventually have a solution, but it's not there yet; and lots
of people are still on NFS 3).  Therefore, if you use NFS storage (which
is surprisingly common when setting up shared storage for migration
purposes), you have to enable the 'virt_use_nfs' SELinux bool, but this
means that SELinux no longer prevents qemu from opening _any_ file
residing on NFS, and thus a compromised guest could read or even write
disk images associated with unrelated guests.  But if qemu is forced to
use only the fds that it inherits from management, then we won't need
the virt_use_nfs sledgehammer, or its loss of security when enabled.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130128/8ad99e55/attachment-0001.sig>