December 2015 - Devel - libvirt List Archives

[libvirt] [PATCH 0/5] virStorageBackendWipeLocal cleanups
by Ján Tomko 17 Dec '15

17 Dec '15

The first patch fixes the return values of virStorageWipe on non-sparse local files in the case of a partial wipe or a fdatasync error. The rest reduces the number of parameters of virStorageBackendWipe{Extent,}Local. Ján Tomko (5): storage: fix return values of virStorageBackendWipeExtentLocal storage: move buffer allocation inside virStorageBackendWipeExtentLocal storage: drop 'Extent' from virStorageBackendWipeExtentLocal virStorageBackendWipeLocal: use unsigned long long instead of off_t virStorageBackendWipeLocal: remove bytes_wiped argument src/storage/storage_backend.c | 53 +++++++++++++++++-------------------------- 1 file changed, 21 insertions(+), 32 deletions(-) -- 2.4.6

2 8

[libvirt] [PATCH v2 0/7] Memory locking limit improvements
by Andrea Bolognani 17 Dec '15

17 Dec '15

During my testing, I've realized that even with the series applied there's still one case in which we're unable to restore the previous memory locking limit after removing the last PCI hostdev from the guest. If an x86 guest contains a PCI hostdev in its XML definition, then the memory locking limit will be set correctly, but virCommandGetMaxMemLock() will be used instead of virProcessGetMaxMemLock(), and the limit will be set right before calling exec() to spawn the qemu binary. In this context, we have no access to the virDomainObj or even virDomainDef instances, so I see no way of storing the original limit for later retrieval. The series is still an improvement as it covers all other cases. Still, I thought this was worth mentioning. Changes since v1[1]: * reorder commits according to John's suggestions * don't fail if we can't retrieve the current memory locking limit * small changes here and there as pointed out during review Cheers. [1] https://www.redhat.com/archives/libvir-list/2015-November/msg01021.html Andrea Bolognani (7): process: Allow virProcessPrLimit() to get current limit process: Add virProcessGetMaxMemLock() qemu: Add qemuDomainAdjustMaxMemLock() qemu: Use qemuDomainAdjustMaxMemLock() qemu: Reduce memlock limit after detaching PCI hostdev qemu: Allow qemuDomainAdjustMaxMemLock() to restore previous value qemu: Replace Mlock with MemLock in function names configure.ac | 2 +- src/conf/domain_conf.h | 3 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 4 ++-- src/qemu/qemu_domain.c | 53 ++++++++++++++++++++++++++++++++++++++--- src/qemu/qemu_domain.h | 5 ++-- src/qemu/qemu_hotplug.c | 45 ++++++++++++++--------------------- src/util/virprocess.c | 61 +++++++++++++++++++++++++++++++++++++++++++----- src/util/virprocess.h | 2 ++ 9 files changed, 135 insertions(+), 41 deletions(-) -- 2.5.0

2 9

[libvirt] [PATCH] build: disable vbox on cygwin
by Eric Blake 17 Dec '15

17 Dec '15

Cygwin cannot build the vbox driver yet: CC vbox/libvirt_driver_vbox_impl_la-vbox_glue.lo In file included from vbox/vbox_glue.c:27:0: vblox/vbox_XPCOMCGlue.c:63:3: error: #error "Port me" # error "Port me" ^ In file included from vbox/vbox_XPCOMCGlue.c:45:0, from vbox/vbox_glue.c:27: vbox/vbox_XPCOMCGlue.c: In function 'tryLoadOne': vbox/vbox_XPCOMCGlue.c:98:46: error: 'DYNLIB_NAME' undeclared (first use in this function) if (virAsprintf(&name, "%s/%s", dir, DYNLIB_NAME) < 0) ^ ./util/virstring.h:245:31: note: in definition of macro 'virAsprintf' strp, __VA_ARGS__) ^ Rather than trying to figure out how to get dynamic loading of vbox to work under cygwin (since I don't even have a working vbox setup to test whether it works), I'm going to be lazy and just default to not even trying vbox on cygwin. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Not technically a build-breaker, since I can './configure --without-vbox' to work around it, so I'll wait for a review. configure.ac | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 75e95b7..2c34333 100644 --- a/configure.ac +++ b/configure.ac @@ -175,12 +175,13 @@ dnl are also linux specific. The "network" and storage_fs drivers are known dnl to not work on MacOS X presently, so we also make a note if compiling dnl for that -with_linux=no with_osx=no with_freebsd=no +with_linux=no with_osx=no with_freebsd=no with_win=no with_cygwin=no case $host in *-*-linux*) with_linux=yes ;; *-*-darwin*) with_osx=yes ;; *-*-freebsd*) with_freebsd=yes ;; *-*-mingw* | *-*-msvc* ) with_win=yes ;; + *-*-cygwin*) with_cygwin=yes ;; esac if test $with_linux = no; then @@ -192,9 +193,12 @@ if test $with_linux = no; then fi if test $with_freebsd = yes; then - want_ifconfig=yes + want_ifconfig=yes + with_firewalld=no +fi - with_firewalld=no +if test $with_cygwin = yes; then + with_vbox=no fi AM_CONDITIONAL([WITH_LINUX], [test "$with_linux" = "yes"]) -- 2.4.3

2 2

[libvirt] LSN-2015-0004: CVE-2015-5313: ACL bypass using ../ to access beyond storage pool
by Eric Blake 17 Dec '15

17 Dec '15

Libvirt Security Notice: LSN-2015-0004 ====================================== Summary: ACL bypass using ../ to access beyond storage pool Reported on: 20151030 Published on: 20151211 Fixed on: 20151211 Reported by: Ossi Herrala <vulncoord(a)ficora.fi> Joonas Kuorilehto <vulncoord(a)ficora.fi> Patched by: Eric Blake <eblake(a)redhat.com> See also: CVE-2015-5313, FICORA bug #876194 Description ----------- Various virStorageVol* API operate on user-supplied volume names by concatenating the volume name to the pool location. Note that the virStoragePoolListVolumes API, when used on a storage pool backed by a directory in a file system, will only list volumes immediately in that directory (there is no traversal into subdirectories). However, other APIs such as virStorageVolCreateXML were not checking if a potential volume name represented one of the volumes that could be returned by virStoragePoolListVolumes; because they were not rejecting the use of '/' in a volume name. Impact ------ Because no checking was done on volume names, a user could supply a potential volume name of something like '../../../etc/passwd' to attempt to access a file not belonging to the storage pool. When fine-grained Access Control Lists (ACL) are in effect, a user with storage_vol:create ACL permission but lacking domain:write permssion could thus abuse virStorageVolCreateXML and similar APIs to gain access to files not normally permitted to that user. Fortunately, it appears that the only APIs that could leak information or corrupt files require read-write connection to libvirtd; and when ACLs are not in use (the default without any further configuration), a user with read-write access can already be considered to have full access to the machine, and without an escalation of privilege there is no security problem. Workaround ---------- If fine-grained ACLs must be used, administrators must consider all of the storage_vol:* permissions as equivalent to domain:write when running an impacted version of libvirt. The easiest way to prevent untrusted users from gaining unauthorized access to volumes outside of permitted pools is by disabling the use of fine-graned ACLs, and ensuring that such users do not have read-write access to libvirtd. Affected product ---------------- Name: libvirt Repository: git://libvirt.org/git/libvirt.git http://libvirt.org/git/?p=libvirt.git Branch: master Broken in: v1.1.0 Broken in: v1.1.1 Broken in: v1.1.2 Broken in: v1.1.3 Broken in: v1.1.4 Broken in: v1.2.0 Broken in: v1.2.1 Broken in: v1.2.2 Broken in: v1.2.3 Broken in: v1.2.4 Broken in: v1.2.5 Broken in: v1.2.6 Broken in: v1.2.7 Broken in: v1.2.8 Broken in: v1.2.9 Broken in: v1.2.10 Broken in: v1.2.11 Broken in: v1.2.12 Broken in: v1.2.13 Broken in: v1.2.14 Broken in: v1.2.15 Broken in: v1.2.16 Broken in: v1.2.17 Broken in: v1.2.18 Broken in: v1.2.19 Broken in: v1.2.20 Broken in: v1.2.20 Broken in: v1.3.0 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 034e47c338b13a95cf02106a3af912c1c5f818d7 Branch: v1.1.0-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 14828a59eadc7221326198a8d7af817a6b8b8c13 Branch: v1.1.1-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 692ce509efa0a07f2811d0fe3b7202b020c874e0 Branch: v1.1.2-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: e8643ef68c99e9f5068f6ff64ea0acab94cac7f6 Branch: v1.1.3-maint Broken in: v1.1.3.1 Broken in: v1.1.3.2 Broken in: v1.1.3.3 Broken in: v1.1.3.4 Broken in: v1.1.3.5 Broken in: v1.1.3.6 Broken in: v1.1.3.7 Broken in: v1.1.3.8 Broken in: v1.1.3.9 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: dcce665904b8ebc9ac3e5109db179a567b33e1a2 Branch: v1.1.4-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: dc2db111a9ba074589c54b90c89f33c01b1e4941 Branch: v1.2.0-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: d414ecb8e1714704e6515ab01ef9386d89b8051e Branch: v1.2.1-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 02d365dae595a3453fe0e438bc274ccf3c18e20d Branch: v1.2.2-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 6542e643024ca4272f14e9052b3786378f6eec62 Branch: v1.2.3-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 91898c606496b14e0891af31dfca7eb77ba9fee3 Branch: v1.2.4-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: c9450f4f855736ef3024dfbab403a849110d8bb5 Branch: v1.2.5-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 890fc0f1ffcc479b08b9fd01de31b62e3d9e7427 Branch: v1.2.6-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 6ae433938377e1b7e657c34cca39e52426347cb4 Branch: v1.2.7-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 4ed8074672f9b847a10464d9c6be77d428c1eb1c Branch: v1.2.8-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 54be99a717873524798d39f8baf49e45054192c8 Branch: v1.2.9-maint Broken in: v1.2.9.1 Broken in: v1.2.9.2 Broken in: v1.2.9.3 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: b0f88836e5eb5b7156bda99c005cf4aa0456ed0d Branch: v1.2.10-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 53ae31bf4df364a2110f636d5482b21af4e4a0cc Branch: v1.2.11-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 0060c4ee9e70a9f6f297373cb4fd2ace6c187be0 Branch: v1.2.12-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: b5ddfbc0fe13a7910c2303056ddd5df749bcf8b0 Branch: v1.2.13-maint Broken in: v1.2.13.1 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: b553ec764f7ecdf8962efbf849a0e8524bae610c Branch: v1.2.14-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 6410a22743fadc3b554b2f0866c9ab8008ff4908 Branch: v1.2.15-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 01cbfeb7d81498db3c644404980c9c1aa9cac048 Branch: v1.2.16-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 3e6b40e5aa3edf47443f017a42ec7b87855ed847 Branch: v1.2.17-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 08acad56ce2e5bcfcca8600a4e4074d3aaeb44dd Branch: v1.2.18-maint Broken in: v1.2.18.1 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: d035796675ca42795953828d11f902f691fa6b29 Branch: v1.2.19-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 69548d200409d2b0dd6356fccfd59570fb58e23a Branch: v1.2.20-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: edeef640db625d23700011dc94adff6e29b85cd3 Branch: v1.2.21-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 29b4ce46798519b93a6a17a5e3734ea4f68ea69d Branch: v1.3.0-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 1d8bcbb7c68d3f35689daf727bc74fcf80a3a6b1 -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

1 0

[libvirt] [PATCH 0/5] Fix issues with activating pool with invalid source
by John Ferlan 17 Dec '15

17 Dec '15

These patches resolve issues with 'FS', 'NFS', and 'LOGICAL' pools where if the pool source device didn't match the reality what was running on the host there were inconsistent results. For the file pools, a pool would be declared 'active' after restart even though a start would fail because the check code only cared that the device the pool was using was mounted. Patches 3 alters the check to not only make sure the device is mounted, but that the source for the device matches the source used to start the pool. For the logical pool, a pool could be both started and declared 'active' on restart as long as the "pool->def->source.name" was a valid volume group on the host even though the pool's source device(s) didn't match the same volume group. Usually the pool build process takes care of ensuring not only that the source device exists, but matching the device(s) to the volume group name create (via vgcreate). The reality is pool startup never checked that the volume group name being used by the pool matched the reality of the volume group on the host. Patch 5 will now ensure not only startup matches the name and device list, but that restart setting 'active' would do the same. John Ferlan (5): storage: Create helper to generate FS pool source value storage: Refactor virStorageBackendFileSystemGetPoolSource storage: Check FS pool source during virStorageBackendFileSystemIsMounted storage: Create helper for virStorageBackendLogicalFindPoolSources storage: Add helper to compare logical pool def against pvs output src/storage/storage_backend_fs.c | 73 ++++++++++++----- src/storage/storage_backend_logical.c | 148 +++++++++++++++++++++++++++++----- 2 files changed, 182 insertions(+), 39 deletions(-) -- 2.5.0

3 15

[libvirt] [PATCH 0/6] Add build options to pool create[-as] and start
by John Ferlan 17 Dec '15

17 Dec '15

https://bugzilla.redhat.com/show_bug.cgi?id=830056 Add the capability to build the pool during pool creation or startup NOTE: If patches 2-4 regarding usage of #define for repeated command options are acceptible, I can start doing the same for other virsh commands. I just found it easier and I think better than the need to continually cut-n-paste for each command option entry. If it's preferred to keep cut-n-paste'ing, then I can modify patch 5 & 6 to follow that model. NOTE: Based loosely on patches posted quite a while ago by Osier Yang before he left Red Hat, see: (Cover) https://www.redhat.com/archives/libvir-list/2012-July/msg00494.html and (libvirt API, storage driver changes) https://www.redhat.com/archives/libvir-list/2012-July/msg01328.html and (virsh changes) https://www.redhat.com/archives/libvir-list/2012-July/msg00497.html John Ferlan (6): storage: Add flags to allow building pool during create processing virsh: Create macro for "pool" option virsh: Create macro for "file" option virsh: Create macro for "overwrite" and no-overwrite" options virsh: Create a macro for pool-define-as and pool-create-as options virsh: Add build flags to pool-create[-as] and pool-start include/libvirt/libvirt-storage.h | 16 +- src/libvirt-storage.c | 4 +- src/storage/storage_driver.c | 42 ++++- tools/virsh-pool.c | 360 ++++++++++++++++++++++---------------- tools/virsh.pod | 25 ++- 5 files changed, 288 insertions(+), 159 deletions(-) -- 2.5.0

3 23

[libvirt] [PATCHv2 0/2] notify about reverting to snapshot
by Dmitry Andreev 17 Dec '15

17 Dec '15

Reverting to snapshot may change domain configuration but there will be no events about that. Lack of the event become a problem for virt-manager https://bugzilla.redhat.com/show_bug.cgi?id=1081148 This patch-set introduces new event and emits it in qemuDomainRevertToSnapshot. v2: [2/2] Reworked. John noted that in some error cases I send 'defined' event without changes in configuration. Dmitry Andreev (2): Introduce new VIR_DOMAIN_EVENT_DEFINED_FROM_SNAPSHOT event qemu: emit 'defined' event after reverted to snapshot examples/object-events/event-test.c | 2 ++ include/libvirt/libvirt-domain.h | 1 + src/qemu/qemu_driver.c | 13 +++++++++++-- tools/virsh-domain.c | 3 ++- 4 files changed, 16 insertions(+), 3 deletions(-) -- 1.8.3.1

3 7

[libvirt] [PATCH] qemu: Search all nodes for shared memory access
by Martin Kletzander 16 Dec '15

16 Dec '15

In commit 686eb7a24f7d, the break was not considered part of the condition, hence breaking after first node when searching. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Pushed as 'trivial' and also John ACKed it earlier. src/qemu/qemu_process.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index ba8dfebd1357..f2740687f655 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4781,9 +4781,10 @@ qemuProcessLaunch(virConnectPtr conn, if (!shmem && vm->def->mem.nhugepages) { for (i = 0; i < virDomainNumaGetNodeCount(vm->def->numa); i++) { if (virDomainNumaGetNodeMemoryAccessMode(vm->def->numa, i) == - VIR_NUMA_MEM_ACCESS_SHARED) + VIR_NUMA_MEM_ACCESS_SHARED) { shmem = true; - break; + break; + } } } -- 2.6.4

1 0

[libvirt] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.
by Ian Campbell 16 Dec '15

16 Dec '15

Upstream Xen is in the process of splitting the (stable API) xtl_* interfaces out from the (unstable API) libxenctrl library and into a new (stable API) libxentoollog. In order to be compatible with Xen both before and after this transition check for xtl_createlogger_stdiostream in a libxentoollog library and use it if present. If it is not present assume it is in libxenctrl. Compile tested on Xen 4.6 and a development tree with the split in place. Signed-off-by: Ian Campbell <ian.campbell(a)citrix.com> --- I'm waiting on applying the upstream change until downstreams are prepared for this. The latest upstream patch is http://lists.xen.org/archives/html/xen-devel/2015-12/msg00454.html which had to be reverted because I had somehow not properly checked if libvirt used this interface http://lists.xen.org/archives/html/xen-devel/2015-12/msg01153.html It might be nice to get this into 1.3.0 so that supports Xen 4.7 out of the box? Not sure what the libvirt stable backport policy is but it might also be good to eventually consider it for that? --- configure.ac | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 98cf210..b641cc7 100644 --- a/configure.ac +++ b/configure.ac @@ -883,7 +883,6 @@ if test "$with_libxl" != "no" ; then PKG_CHECK_MODULES([LIBXL], [xenlight], [ LIBXL_FIRMWARE_DIR=`$PKG_CONFIG --variable xenfirmwaredir xenlight` LIBXL_EXECBIN_DIR=`$PKG_CONFIG --variable libexec_bin xenlight` - LIBXL_LIBS="$LIBXL_LIBS -lxenctrl" with_libxl=yes ], [LIBXL_FOUND=no]) if test "$LIBXL_FOUND" = "no"; then @@ -896,7 +895,7 @@ if test "$with_libxl" != "no" ; then LIBS="$LIBS $LIBXL_LIBS" AC_CHECK_LIB([xenlight], [libxl_ctx_alloc], [ with_libxl=yes - LIBXL_LIBS="$LIBXL_LIBS -lxenlight -lxenctrl" + LIBXL_LIBS="$LIBXL_LIBS -lxenlight" ],[ if test "$with_libxl" = "yes"; then fail=1 @@ -924,6 +923,14 @@ if test "$with_libxl" = "yes"; then if test "x$LIBXL_EXECBIN_DIR" != "x"; then AC_DEFINE_UNQUOTED([LIBXL_EXECBIN_DIR], ["$LIBXL_EXECBIN_DIR"], [directory containing Xen libexec binaries]) fi + dnl Check if the xtl_* infrastructure is in libxentoollog + dnl (since Xen 4.7) if not then assume it is in libxenctrl + dnl (as it was for 4.6 and earler) + AC_CHECK_LIB([xentoollog], [xtl_createlogger_stdiostream], [ + LIBXL_LIBS="$LIBXL_LIBS -lxentoollog" + ],[ + LIBXL_LIBS="$LIBXL_LIBS -lxenctrl" + ]) fi AM_CONDITIONAL([WITH_LIBXL], [test "$with_libxl" = "yes"]) -- 2.1.4

3 4

[libvirt] [PATCH 0/5] UEFI loader NVRAM image in Qcow2 format
by Dmitry Andreev 16 Dec '15

16 Dec '15

Libvirt allows to specify a path to an image file that will be used as a var storage for UEFI firmware. <nvram>/var/lib/libvirt/nvram/guest_VARS.fd</nvram> By default this image is created as a copy of a master image. The master image and it's copy are stored in 'raw' format. Qemu isn't able to create snapshot for an image in 'raw' format. That makes snapshotting impossible for any UEFI configuration. If the image with UEFI nvram is converted to Qcow2 format (and qemu command is modified appropriately), snapshotting works fine. In the patch-set I introduce 'format' attribute for nvram tag that specifies nvram image file format. The patch-set doesn't contains docs and test in v1. Dmitry Andreev (5): storage: split virStorageBackendCreateExecCommand in two functions storage: refactor: split out image creating tool search function storage: add new function virStorageBackendConvertImage conf: add 'format' attribute to domain/os/nvram element qemu: add support for os.nvram 'format' attribute docs/schemas/domaincommon.rng | 8 ++ src/conf/domain_conf.c | 18 +++++ src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 8 +- src/qemu/qemu_process.c | 17 ++++ src/storage/storage_backend.c | 181 ++++++++++++++++++++++++++---------------- src/storage/storage_backend.h | 5 ++ 7 files changed, 167 insertions(+), 71 deletions(-) -- 1.8.3.1

3 9