[libvirt] [PATCH v2 0/7] Memory locking limit improvements
by Andrea Bolognani
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
9 years
[libvirt] [PATCH] build: disable vbox on cygwin
by Eric Blake
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
9 years
[libvirt] LSN-2015-0004: CVE-2015-5313: ACL bypass using ../ to access beyond storage pool
by Eric Blake
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
9 years
[libvirt] [PATCH 0/5] Fix issues with activating pool with invalid source
by John Ferlan
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
9 years
[libvirt] [PATCHv2 0/2] notify about reverting to snapshot
by Dmitry Andreev
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
9 years
[libvirt] [PATCH] qemu: Search all nodes for shared memory access
by Martin Kletzander
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
9 years
[libvirt] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.
by Ian Campbell
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
9 years
[libvirt] [PATCH 0/5] UEFI loader NVRAM image in Qcow2 format
by Dmitry Andreev
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
9 years
[libvirt] [PATCH v2] vz: implementation of domainCreateXML callback
by Mikhail Feoktistov
---
diff from v1.
Remove call of vzDomainSuspend() in case of VIR_DOMAIN_START_PAUSED flag is set.
Now we don't support to create instance in stopped state.
src/vz/vz_driver.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c
index ea1090a..4498e01 100644
--- a/src/vz/vz_driver.c
+++ b/src/vz/vz_driver.c
@@ -979,6 +979,29 @@ vzDomainUndefine(virDomainPtr domain)
return vzDomainUndefineFlags(domain, 0);
}
+static virDomainPtr
+vzDomainCreateXML(virConnectPtr conn,
+ const char *xml,
+ unsigned int flags)
+{
+ virDomainPtr domain;
+ int ret;
+
+ virCheckFlags(0, NULL);
+
+ domain = vzDomainDefineXMLFlags(conn, xml, 0);
+ if (domain == NULL)
+ return domain;
+
+ ret = vzDomainCreate(domain);
+ if (ret != 0) {
+ vzDomainUndefine(domain);
+ return NULL;
+ }
+
+ return domain;
+}
+
static int
vzDomainHasManagedSaveImage(virDomainPtr domain, unsigned int flags)
{
@@ -1493,6 +1516,7 @@ static virHypervisorDriver vzDriver = {
.domainShutdown = vzDomainShutdown, /* 0.10.0 */
.domainCreate = vzDomainCreate, /* 0.10.0 */
.domainCreateWithFlags = vzDomainCreateWithFlags, /* 1.2.10 */
+ .domainCreateXML = vzDomainCreateXML, /* 1.2.22 */
.domainReboot = vzDomainReboot, /* 1.3.0 */
.domainDefineXML = vzDomainDefineXML, /* 0.10.0 */
.domainDefineXMLFlags = vzDomainDefineXMLFlags, /* 1.2.12 */
--
1.8.3.1
9 years
