- 20 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Based on work of Mehdi Abaakouk <sileht@sileht.net>. When parsing vhost-user interface XML and no ifname is found we can try to fill it in in post parse callback. The way this works is we try to make up interface name from given socket path and then ask openvswitch whether it knows the interface. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 17 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1413922 While all the code that deals with qemu namespaces correctly detects whether we are running as root (and turn into NO-OP for qemu:///session) the actual unshare() call is not guarded with such check. Therefore any attempt to start a domain under qemu:///session shall fail as unshare() is reserved for root. The fix consists of moving unshare() call (for which we have a wrapper called virProcessSetupPrivateMountNS) into qemuDomainBuildNamespace() where the proper check is performed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Tested-by: NRichard W.M. Jones <rjones@redhat.com>
-
- 13 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
When creating new /dev/* for qemu, we do chown() and copy ACLs to create the exact copy from the original /dev. I though that copying SELinux labels is not necessary as SELinux will chose the sane defaults. Surprisingly, it does not leaving namespace with the following labels: crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 random crw-------. root root system_u:object_r:tmpfs_t:s0 rtc0 drwxrwxrwt. root root system_u:object_r:tmpfs_t:s0 shm crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 urandom As a result, domain is unable to start: error: internal error: process exited while connecting to monitor: Error in GnuTLS initialization: Failed to acquire random data. qemu-kvm: cannot initialize crypto: Unable to initialize GNUTLS library: Failed to acquire random data. The solution is to copy the SELinux labels as well. Reported-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 1月, 2017 4 次提交
-
-
由 Michal Privoznik 提交于
So far the decision whether /dev/* entry is created in the qemu namespace is really simple: does the path starts with "/dev/"? This can be easily fooled by providing path like the following (for any considered device like disk, rng, chardev, ..): /dev/../var/lib/libvirt/images/disk.qcow2 Therefore, before making the decision the path should be canonicalized. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So far the namespaces were turned on by default unconditionally. For all non-Linux platforms we provided stub functions that just ignored whatever namespaces setting there was in qemu.conf and returned 0 to indicate success. Moreover, we didn't really check if namespaces are available on the host kernel. This is suboptimal as we might have ignored user setting. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This is a simple wrapper over mount(). However, not every system out there is capable of moving a mount point. Therefore, instead of having to deal with this fact in all the places of our code we can have a simple wrapper and deal with this fact at just one place. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Due to a copy-paste error, the debug message reads: Setting up disks It should have been: Setting up inputs. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 11 1月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
This function is used only from code compiled on Linux. Therefore on non-Linux platforms it triggers compilation error: ../../src/qemu/qemu_domain.c:209:1: error: unused function 'qemuDomainGetPreservedMounts' [-Werror,-Wunused-function] Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 1月, 2017 4 次提交
-
-
由 Michal Privoznik 提交于
After previous commits, this function is no longer needed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Again, there is no need to create /var/lib/libvirt/$domain.* directories in CreateNamespace(). It is sufficient to create them as soon as we need them which is in BuildNamespace. This way we don't leave them around for the whole lifetime of domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The c1140eb9 got me thinking. We don't want to special case /dev in qemuDomainGetPreservedMounts(), but in all other places in the code we special case it anyway. I mean, /var/run/libvirt/$domain.dev path is constructed separately just so that it is not constructed here. It makes only a little sense (if any at all). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
If something goes wrong in this function we try a rollback. That is unlink all the directories we created earlier. For some weird reason unlink() was called instead of rmdir(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 05 1月, 2017 2 次提交
-
-
由 Martin Kletzander 提交于
Just so it doesn't bite us in the future, even though it's unlikely. And fix the comment above it as well. Commit e08ee7cd took the info from the function it's calling, but that was lie itself in the first place. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Michal Privoznik 提交于
With my namespace patches, we are spawning qemu in its own namespace so that we can manage /dev entries ourselves. However, some filesystems mounted under /dev needs to be preserved in order to be shared with the parent namespace (e.g. /dev/pts). Currently, the list of mount points to preserve is hardcoded which ain't right - on some systems there might be less or more items under real /dev that on our list. The solution is to parse /proc/mounts and fetch the list from there. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 04 1月, 2017 4 次提交
-
-
由 Michal Privoznik 提交于
Again, not something that I'd hit, but there is a chance in theory that this might bite us. Currently the way we decide whether or not to create /dev entry for a device is by marching first four characters of path with "/dev". This might be not enough. Just imagine somebody has a disk image stored under "/devil/path/to/disk". We ought to be matching against "/dev/". Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Not that I'd encounter any bug here, but the code doesn't look 100% correct. Imagine, somebody is trying to attach a device to a domain, and the device's /dev entry already exists in the qemu namespace. This is handled gracefully and the control continues with setting up ACLs and calling security manager to set up labels. Now, if any of these steps fail, control jump on the 'cleanup' label and unlink() the file straight away. Even when it was not us who created the file in the first place. This can be possibly dangerous. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1406837 Imagine you have a domain configured in such way that you are assigning two PCI devices that fall into the same IOMMU group. With mount namespace enabled what happens is that for the first PCI device corresponding /dev/vfio/X entry is created and when the code tries to do the same for the second mknod() fails as /dev/vfio/X already exists: 2016-12-21 14:40:45.648+0000: 24681: error : qemuProcessReportLogError:1792 : internal error: Process exited prior to exec: libvirt: QEMU Driver error : Failed to make device /var/run/libvirt/qemu/windoze.dev//vfio/22: File exists Worse, by default there are some devices that are created in the namespace regardless of domain configuration (e.g. /dev/null, /dev/urandom, etc.). If one of them is set as backend for some guest device (e.g. rng, chardev, etc.) it's the same story as described above. Weirdly, in attach code this is already handled. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1405269 If a secret was not provided for what was determined to be a LUKS encrypted disk (during virStorageFileGetMetadata processing when called from qemuDomainDetermineDiskChain as a result of hotplug attach qemuDomainAttachDeviceDiskLive), then do not attempt to look it up (avoiding a libvirtd crash) and do not alter the format to "luks" when adding the disk; otherwise, the device_add would fail with a message such as: "unable to execute QEMU command 'device_add': Property 'scsi-hd.drive' can't find value 'drive-scsi0-0-0-0'" because of assumptions that when the format=luks that libvirt would have provided the secret to decrypt the volume. Access to unlock the volume will thus be left to the application.
-
- 20 12月, 2016 1 次提交
-
-
由 Marc Hartmayer 提交于
Disk->info is not live updatable so add a check for this. Otherwise libvirt reports success even though no data was updated. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
- 16 12月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
Some of the functions are not called on non-linux platforms which makes them useless there. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 15 12月, 2016 13 次提交
-
-
由 Michal Privoznik 提交于
Given how intrusive previous patches are, it might happen that there's a bug or imperfection. Lets give users a way out: if they set 'namespaces' to an empty array in qemu.conf the feature is suppressed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When attaching a device to a domain that's using separate mount namespace we must maintain /dev entries in order for qemu process to see them. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When attaching a device to a domain that's using separate mount namespace we must maintain /dev entries in order for qemu process to see them. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When attaching a device to a domain that's using separate mount namespace we must maintain /dev entries in order for qemu process to see them. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When attaching a device to a domain that's using separate mount namespace we must maintain /dev entries in order for qemu process to see them. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When starting a domain and separate mount namespace is used, we have to create all the /dev entries that are configured for the domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When starting a domain and separate mount namespace is used, we have to create all the /dev entries that are configured for the domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When starting a domain and separate mount namespace is used, we have to create all the /dev entries that are configured for the domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When starting a domain and separate mount namespace is used, we have to create all the /dev entries that are configured for the domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When starting a domain and separate mount namespace is used, we have to create all the /dev entries that are configured for the domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When starting a domain and separate mount namespace is used, we have to create all the /dev entries that are configured for the domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Prime time. When it comes to spawning qemu process and relabelling all the devices it's going to touch, there's inherent race with other applications in the system (e.g. udev). Instead of trying convincing udev to not touch libvirt managed devices, we can create a separate mount namespace for the qemu, and mount our own /dev there. Of course this puts more work onto us as we have to maintain /dev files on each domain start and device hot(un-)plug. On the other hand, this enhances security also. From technical POV, on domain startup process the parent (libvirtd) creates: /var/lib/libvirt/qemu/$domain.dev /var/lib/libvirt/qemu/$domain.devpts The child (which is going to be qemu eventually) calls unshare() to create new mount namespace. From now on anything that child does is invisible to the parent. Child then mounts tmpfs on $domain.dev (so that it still sees original /dev from the host) and creates some devices (as explained in one of the previous patches). The devices have to be created exactly as they are in the host (including perms, seclabels, ACLs, ...). After that it moves $domain.dev mount to /dev. What's the $domain.devpts mount there for then you ask? QEMU can create PTYs for some chardevs. And historically we exposed the host ends in our domain XML allowing users to connect to them. Therefore we must preserve devpts mount to be shared with the host's one. To make this patch as small as possible, creating of devices configured for domain in question is implemented in next patches. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
- 08 12月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
So far this function takes virDomainObjPtr which: 1) is an overkill, 2) might be not available in all the places we will use it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 01 12月, 2016 1 次提交
-
-
由 Laine Stump 提交于
If libvirtd is running unprivileged, it can open a device's PCI config data in sysfs, but can only read the first 64 bytes. But as part of determining whether a device is Express or legacy PCI, qemuDomainDeviceCalculatePCIConnectFlags() will be updated in a future patch to call virPCIDeviceIsPCIExpress(), which tries to read beyond the first 64 bytes of the PCI config data and fails with an error log if the read is unsuccessful. In order to avoid creating a parallel "quiet" version of virPCIDeviceIsPCIExpress(), this patch passes a virQEMUDriverPtr down through all the call chains that initialize the qemuDomainFillDevicePCIConnectFlagsIterData, and saves the driver pointer with the rest of the iterdata so that it can be used by qemuDomainDeviceCalculatePCIConnectFlags(). This pointer isn't used yet, but will be used in an upcoming patch (that detects Express vs legacy PCI for VFIO assigned devices) to examine driver->privileged.
-
- 25 11月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
We have couple of functions that operate over NULL terminated lits of strings. However, our naming sucks: virStringJoin virStringFreeList virStringFreeListCount virStringArrayHasString virStringGetFirstWithPrefix We can do better: virStringListJoin virStringListFree virStringListFreeCount virStringListHasString virStringListGetFirstWithPrefix Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 23 11月, 2016 2 次提交
-
-
由 Nikolay Shirokovskiy 提交于
qemuDomainObjExitAgent is unsafe. First it accesses domain object without domain lock. Second it uses outdated logic that goes back to commit 79533da1 of year 2009 when code was quite different. (unref function instead of unreferencing only unlocked and disposed object in case of last reference and leaved unlocking to the caller otherwise). Nowadays this logic may lead to disposing locked object i guess. Another problem is that the callers of qemuDomainObjEnterAgent use domain object again (namely priv->agent) without domain lock. This patch address these two problems. qemuDomainGetAgent is dropped as unused.
-
由 Nikolay Shirokovskiy 提交于
-
- 22 11月, 2016 2 次提交
-
-
由 Marc Hartmayer 提交于
Use the util function virHostdevIsSCSIDevice() to simplify if statements. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
由 Marc Hartmayer 提交于
Add missing checks if a hostdev is a subsystem/SCSI device before access the union member 'subsys'/'scsi'. Also fix indentation and simplify qemuDomainObjCheckHostdevTaint(). Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-