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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list