- Devel - libvirt List Archives

[libvirt] [PATCH 0/5] Revert and fix PCI bridge auto-add to extend default bus
by Erik Skultety 23 Jan '15

23 Jan '15

Erik Skultety (5): qemu: Remove dead code in qemuDomainAssignPCIAddresses revert patch conf: virDomainDefMaybeAddController tweak return code qemu: Fix auto-adding PCI bridge when all slots are reserved qemu: move PCI slot assignment for PIIX3, Q35 into a separate function qemu: reorder PCI slot assignment functions src/conf/domain_conf.c | 2 +- src/qemu/qemu_command.c | 264 ++++++++++++++++++++++++++++-------------------- 2 files changed, 154 insertions(+), 112 deletions(-) -- 1.9.3

2 11

[libvirt] [PATCH 0/3] Update example apparmor profile
by Mike Latimer 23 Jan '15

23 Jan '15

The apparmor profile example for libvirtd is rather outdated. The changes in this patch series are intended to bring this sample up to date with the latest working configuration. This series addresses issues applicable to general libvirt, Xen and libvirt-TCK operations - each in their own patch. Mike Latimer (3): Fix apparmor issues for Xen Grant access to helpers Fix apparmor issues for tck examples/apparmor/usr.sbin.libvirtd | 6 ++++++ 1 file changed, 6 insertions(+) -- 1.8.4.5

2 10

[libvirt] [PATCH] Fix build with older gcc
by Ján Tomko 23 Jan '15

23 Jan '15

My commit af1c98e4 broke the build on RHEL-6: vircgrouptest.c: In function 'testCgroupGetPercpuStats': vircgrouptest.c:566: error: nested extern declaration of '_gl_verify_function2' [-Wnested-externs] The only thing that needs checking is that the array size is at least EXPECTED_NCPUS, to prevent access beyond the array. We can ensure the minimum size also by specifying the array size upfront. --- tests/vircgrouptest.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Pushed as a build fix. diff --git a/tests/vircgrouptest.c b/tests/vircgrouptest.c index b65ea3f..a455a81 100644 --- a/tests/vircgrouptest.c +++ b/tests/vircgrouptest.c @@ -541,7 +541,7 @@ static int testCgroupGetPercpuStats(const void *args ATTRIBUTE_UNUSED) virTypedParameterPtr params = NULL; # define EXPECTED_NCPUS 160 - unsigned long long expected[] = { + unsigned long long expected[EXPECTED_NCPUS] = { 0, 0, 0, 0, 0, 0, 0, 0, 7059492996, 0, 0, 0, 0, 0, 0, 0, 4180532496, 0, 0, 0, 0, 0, 0, 0, @@ -563,7 +563,6 @@ static int testCgroupGetPercpuStats(const void *args ATTRIBUTE_UNUSED) 5683512916, 0, 0, 0, 0, 0, 0, 0, 635751356, 0, 0, 0, 0, 0, 0, 0, }; - verify(ARRAY_CARDINALITY(expected) == EXPECTED_NCPUS); if (VIR_ALLOC_N(params, EXPECTED_NCPUS) < 0) goto cleanup; -- 2.0.4

1 0

[libvirt] [PATCH v3 1/2] systemd: fix build without dbus
by Daniel P. Berrange 23 Jan '15

23 Jan '15

The virDBusMethodCall method has a DBusError as one of its parameters. If the caller wants to pass a non-NULL value for this, it immediately makes the calling code require DBus at build time. This has led to breakage of non-DBus builds several times. It is desirable that only the virdbus.c file should need WITH_DBUS conditionals, so we must ideally remove the DBusError parameter from the method. We can't simply raise a libvirt error, since the whole point of this parameter is to give the callers a way to check if the error is one they want to ignore, without having the logs polluted with an error message. So, we add a virErrorPtr parameter which the caller can then either ignore or raise using the new virReportErrorObject method. This new method is distinct from virSetError in that it ensures the logging hooks are run. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- po/POTFILES.in | 1 - src/libvirt_private.syms | 1 + src/util/virdbus.c | 31 ++++++++------ src/util/virdbus.h | 4 +- src/util/virerror.c | 104 +++++++++++++++++++++++++++++++++++++---------- src/util/virerror.h | 8 ++++ src/util/virfirewall.c | 29 +++---------- src/util/virsystemd.c | 15 ++++--- 8 files changed, 125 insertions(+), 68 deletions(-) diff --git a/po/POTFILES.in b/po/POTFILES.in index 26c098f..3064037 100644 --- a/po/POTFILES.in +++ b/po/POTFILES.in @@ -217,7 +217,6 @@ src/util/virstorageencryption.c src/util/virstoragefile.c src/util/virstring.c src/util/virsysinfo.c -src/util/virsystemd.c src/util/virerror.c src/util/virerror.h src/util/virtime.c diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index a2eec83..528e93c 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -1284,6 +1284,7 @@ virErrorInitialize; virErrorSetErrnoFromLastError; virLastErrorIsSystemErrno; virRaiseErrorFull; +virRaiseErrorObject; virReportErrorHelper; virReportOOMErrorFull; virReportSystemErrorFull; diff --git a/src/util/virdbus.c b/src/util/virdbus.c index d9665c1..3522ae0 100644 --- a/src/util/virdbus.c +++ b/src/util/virdbus.c @@ -1522,7 +1522,7 @@ static int virDBusCall(DBusConnection *conn, DBusMessage *call, DBusMessage **replyout, - DBusError *error) + virErrorPtr error) { DBusMessage *reply = NULL; @@ -1530,8 +1530,9 @@ virDBusCall(DBusConnection *conn, int ret = -1; const char *iface, *member, *path, *dest; - if (!error) - dbus_error_init(&localerror); + dbus_error_init(&localerror); + if (error) + memset(error, 0, sizeof(*error)); iface = dbus_message_get_interface(call); member = dbus_message_get_member(call); @@ -1545,13 +1546,20 @@ virDBusCall(DBusConnection *conn, if (!(reply = dbus_connection_send_with_reply_and_block(conn, call, VIR_DBUS_METHOD_CALL_TIMEOUT_MILLIS, - error ? error : &localerror))) { + &localerror))) { PROBE(DBUS_METHOD_ERROR, "'%s.%s' on '%s' at '%s' error %s: %s", iface, member, path, dest, - error ? error->name : localerror.name, - error ? error->message : localerror.message); + localerror.name, + localerror.message); if (error) { + error->level = VIR_ERR_ERROR; + error->code = VIR_ERR_DBUS_SERVICE; + error->domain = VIR_FROM_DBUS; + if (VIR_STRDUP(error->message, localerror.message) < 0) + goto cleanup; + if (VIR_STRDUP(error->str1, localerror.name) < 0) + goto cleanup; ret = 0; } else { virReportError(VIR_ERR_DBUS_SERVICE, _("%s: %s"), member, @@ -1567,8 +1575,9 @@ virDBusCall(DBusConnection *conn, ret = 0; cleanup: - if (!error) - dbus_error_free(&localerror); + if (ret < 0 && error) + virResetError(error); + dbus_error_free(&localerror); if (reply) { if (ret == 0 && replyout) *replyout = reply; @@ -1616,7 +1625,7 @@ virDBusCall(DBusConnection *conn, */ int virDBusCallMethod(DBusConnection *conn, DBusMessage **replyout, - DBusError *error, + virErrorPtr error, const char *destination, const char *path, const char *iface, @@ -1634,8 +1643,6 @@ int virDBusCallMethod(DBusConnection *conn, if (ret < 0) goto cleanup; - ret = -1; - ret = virDBusCall(conn, call, replyout, error); cleanup: @@ -1832,7 +1839,7 @@ int virDBusCreateReply(DBusMessage **reply ATTRIBUTE_UNUSED, int virDBusCallMethod(DBusConnection *conn ATTRIBUTE_UNUSED, DBusMessage **reply ATTRIBUTE_UNUSED, - DBusError *error ATTRIBUTE_UNUSED, + virErrorPtr error ATTRIBUTE_UNUSED, const char *destination ATTRIBUTE_UNUSED, const char *path ATTRIBUTE_UNUSED, const char *iface ATTRIBUTE_UNUSED, diff --git a/src/util/virdbus.h b/src/util/virdbus.h index d0c7de2..e2b8d2b 100644 --- a/src/util/virdbus.h +++ b/src/util/virdbus.h @@ -28,7 +28,7 @@ # else # define DBusConnection void # define DBusMessage void -# define DBusError void +# define dbus_message_unref(m) do {} while (0) # endif # include "internal.h" @@ -62,7 +62,7 @@ int virDBusCreateReplyV(DBusMessage **reply, int virDBusCallMethod(DBusConnection *conn, DBusMessage **reply, - DBusError *error, + virErrorPtr error, const char *destination, const char *path, const char *iface, diff --git a/src/util/virerror.c b/src/util/virerror.c index f5d7f54..9635c82 100644 --- a/src/util/virerror.c +++ b/src/util/virerror.c @@ -618,6 +618,39 @@ virDispatchError(virConnectPtr conn) } +/* + * Reports an error through the logging subsystem + */ +static +void virRaiseErrorLog(const char *filename, + const char *funcname, + size_t linenr, + virErrorPtr err, + virLogMetadata *meta) +{ + int priority; + + /* + * Hook up the error or warning to the logging facility + */ + priority = virErrorLevelPriority(err->level); + if (virErrorLogPriorityFilter) + priority = virErrorLogPriorityFilter(err, priority); + + /* We don't want to pollute stderr if no logging outputs + * are explicitly requested by the user, since the default + * error function already pollutes stderr and most apps + * hate & thus disable that too. If the daemon has set + * a priority filter though, we should always forward + * all errors to the logging code. + */ + if (virLogGetNbOutputs() > 0 || + virErrorLogPriorityFilter) + virLogMessage(&virLogSelf, + priority, + filename, linenr, funcname, + meta, "%s", err->message); +} /** * virRaiseErrorFull: @@ -639,7 +672,7 @@ virDispatchError(virConnectPtr conn) * immediately if a callback is found and store it for later handling. */ void -virRaiseErrorFull(const char *filename ATTRIBUTE_UNUSED, +virRaiseErrorFull(const char *filename, const char *funcname, size_t linenr, int domain, @@ -655,7 +688,6 @@ virRaiseErrorFull(const char *filename ATTRIBUTE_UNUSED, int save_errno = errno; virErrorPtr to; char *str; - int priority; virLogMetadata meta[] = { { .key = "LIBVIRT_DOMAIN", .s = NULL, .iv = domain }, { .key = "LIBVIRT_CODE", .s = NULL, .iv = code }, @@ -709,30 +741,58 @@ virRaiseErrorFull(const char *filename ATTRIBUTE_UNUSED, to->int1 = int1; to->int2 = int2; - /* - * Hook up the error or warning to the logging facility - */ - priority = virErrorLevelPriority(level); - if (virErrorLogPriorityFilter) - priority = virErrorLogPriorityFilter(to, priority); - - /* We don't want to pollute stderr if no logging outputs - * are explicitly requested by the user, since the default - * error function already pollutes stderr and most apps - * hate & thus disable that too. If the daemon has set - * a priority filter though, we should always forward - * all errors to the logging code. - */ - if (virLogGetNbOutputs() > 0 || - virErrorLogPriorityFilter) - virLogMessage(&virLogSelf, - priority, - filename, linenr, funcname, - meta, "%s", str); + virRaiseErrorLog(filename, funcname, linenr, + to, meta); errno = save_errno; } + +/** + * virRaiseErrorObject: + * @filename: filename where error was raised + * @funcname: function name where error was raised + * @linenr: line number where error was raised + * @newerr: the error object to report + * + * Sets the thread local error object to be a copy of + * @newerr and logs the error + * + * This is like virRaiseErrorFull, except that it accepts the + * error information via a pre-filled virErrorPtr object + * + * This is like virSetError, except that it will trigger the + * logging callbacks. + * + * The caller must clear the @newerr instance afterwards, since + * it will be copied into the thread local error. + */ +void virRaiseErrorObject(const char *filename, + const char *funcname, + size_t linenr, + virErrorPtr newerr) +{ + int saved_errno = errno; + virErrorPtr err; + virLogMetadata meta[] = { + { .key = "LIBVIRT_DOMAIN", .s = NULL, .iv = newerr->domain }, + { .key = "LIBVIRT_CODE", .s = NULL, .iv = newerr->code }, + { .key = NULL }, + }; + + err = virLastErrorObject(); + if (!err) + goto cleanup; + + virResetError(err); + virCopyError(newerr, err); + virRaiseErrorLog(filename, funcname, linenr, + err, meta); + cleanup: + errno = saved_errno; +} + + /** * virErrorMsg: * @error: the virErrorNumber diff --git a/src/util/virerror.h b/src/util/virerror.h index 5c8578f..ad3a946 100644 --- a/src/util/virerror.h +++ b/src/util/virerror.h @@ -47,6 +47,11 @@ void virRaiseErrorFull(const char *filename, const char *fmt, ...) ATTRIBUTE_FMT_PRINTF(12, 13); +void virRaiseErrorObject(const char *filename, + const char *funcname, + size_t linenr, + virErrorPtr err); + void virReportErrorHelper(int domcode, int errcode, const char *filename, const char *funcname, @@ -165,6 +170,9 @@ void virReportOOMErrorFull(int domcode, virReportErrorHelper(VIR_FROM_THIS, code, __FILE__, \ __FUNCTION__, __LINE__, __VA_ARGS__) +# define virReportErrorObject(obj) \ + virRaiseErrorObject(__FILE__, __FUNCTION__, __LINE__, obj) + int virSetError(virErrorPtr newerr); void virDispatchError(virConnectPtr conn); const char *virStrerror(int theerrno, char *errBuf, size_t errBufLen); diff --git a/src/util/virfirewall.c b/src/util/virfirewall.c index b536912..cd7afa5 100644 --- a/src/util/virfirewall.c +++ b/src/util/virfirewall.c @@ -156,7 +156,6 @@ static int virFirewallValidateBackend(virFirewallBackend backend) { VIR_DEBUG("Validating backend %d", backend); -#if WITH_DBUS if (backend == VIR_FIREWALL_BACKEND_AUTOMATIC || backend == VIR_FIREWALL_BACKEND_FIREWALLD) { int rv = virDBusIsServiceRegistered(VIR_FIREWALL_FIREWALLD_SERVICE); @@ -180,16 +179,6 @@ virFirewallValidateBackend(virFirewallBackend backend) backend = VIR_FIREWALL_BACKEND_FIREWALLD; } } -#else - if (backend == VIR_FIREWALL_BACKEND_AUTOMATIC) { - VIR_DEBUG("DBus support disabled, trying direct backend"); - backend = VIR_FIREWALL_BACKEND_DIRECT; - } else if (backend == VIR_FIREWALL_BACKEND_FIREWALLD) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("firewalld firewall backend requested, but DBus support disabled")); - return -1; - } -#endif if (backend == VIR_FIREWALL_BACKEND_DIRECT) { const char *commands[] = { @@ -755,7 +744,6 @@ virFirewallApplyRuleDirect(virFirewallRulePtr rule, } -#ifdef WITH_DBUS static int virFirewallApplyRuleFirewallD(virFirewallRulePtr rule, bool ignoreErrors, @@ -764,13 +752,13 @@ virFirewallApplyRuleFirewallD(virFirewallRulePtr rule, const char *ipv = virFirewallLayerFirewallDTypeToString(rule->layer); DBusConnection *sysbus = virDBusGetSystemBus(); DBusMessage *reply = NULL; - DBusError error; + virError error; int ret = -1; if (!sysbus) return -1; - dbus_error_init(&error); + memset(&error, 0, sizeof(error)); if (!ipv) { virReportError(VIR_ERR_INTERNAL_ERROR, @@ -792,7 +780,7 @@ virFirewallApplyRuleFirewallD(virFirewallRulePtr rule, rule->args) < 0) goto cleanup; - if (dbus_error_is_set(&error)) { + if (error.level == VIR_ERR_ERROR) { /* * As of firewalld-0.3.9.3-1.fc20.noarch the name and * message fields in the error look like @@ -820,11 +808,9 @@ virFirewallApplyRuleFirewallD(virFirewallRulePtr rule, */ if (ignoreErrors) { VIR_DEBUG("Ignoring error '%s': '%s'", - error.name, error.message); + error.str1, error.message); } else { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("Unable to apply rule '%s'"), - error.message); + virReportErrorObject(&error); goto cleanup; } } else { @@ -835,12 +821,11 @@ virFirewallApplyRuleFirewallD(virFirewallRulePtr rule, ret = 0; cleanup: - dbus_error_free(&error); + virResetError(&error); if (reply) dbus_message_unref(reply); return ret; } -#endif static int virFirewallApplyRule(virFirewallPtr firewall, @@ -862,12 +847,10 @@ virFirewallApplyRule(virFirewallPtr firewall, if (virFirewallApplyRuleDirect(rule, ignoreErrors, &output) < 0) return -1; break; -#if WITH_DBUS case VIR_FIREWALL_BACKEND_FIREWALLD: if (virFirewallApplyRuleFirewallD(rule, ignoreErrors, &output) < 0) return -1; break; -#endif default: virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Unexpected firewall engine backend")); diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c index 3eea5c2..6de265b 100644 --- a/src/util/virsystemd.c +++ b/src/util/virsystemd.c @@ -252,8 +252,8 @@ int virSystemdCreateMachine(const char *name, VIR_DEBUG("Attempting to create machine via systemd"); if (virAtomicIntGet(&hasCreateWithNetwork)) { - DBusError error; - dbus_error_init(&error); + virError error; + memset(&error, 0, sizeof(error)); if (virDBusCallMethod(conn, NULL, @@ -280,21 +280,20 @@ int virSystemdCreateMachine(const char *name, "Before", "as", 1, "libvirt-guests.service") < 0) goto cleanup; - if (dbus_error_is_set(&error)) { + if (error.level == VIR_ERR_ERROR) { if (STREQ_NULLABLE("org.freedesktop.DBus.Error.UnknownMethod", - error.name)) { + error.str1)) { VIR_INFO("CreateMachineWithNetwork isn't supported, switching " "to legacy CreateMachine method for systemd-machined"); - dbus_error_free(&error); + virResetError(&error); virAtomicIntSet(&hasCreateWithNetwork, 0); /* Could re-structure without Using goto, but this * avoids another atomic read which would trigger * another memory barrier */ goto fallback; } - virReportError(VIR_ERR_DBUS_SERVICE, - _("CreateMachineWithNetwork: %s"), - error.message ? error.message : _("unknown error")); + virReportErrorObject(&error); + virResetError(&error); goto cleanup; } } else { -- 2.1.0

2 2

Re: [libvirt] Live Migration with Pass-through Devices proposal
by Izumi, Taku 23 Jan '15

23 Jan '15

Hi Chen-san, > Hi all, > > backgrond: > Live migration is one of the most important features of virtualization > technology. > With regard to recent virtualization techniques, performance of network > I/O is critical. > Current network I/O virtualization (e.g. Para-virtualized I/O, VMDq) has > a significant > performance gap with native network I/O. Pass-through network devices > have near > native performance, however, they have thus far prevented live > migration. No existing > methods solve the problem of live migration with pass-through devices > perfectly. > > There was an idea to solve the problem in website: > https://www.kernel.org/doc/ols/2008/ols2008v2-pages-261-267.pdf > Please refer to above document for detailed information. > > So I think this problem maybe could be solved by using the combination > of existing > technology. the attached was the architecture of migration with > passthrough device > we proposed. and the following steps are we considering to implement: > > - before boot VM, we anticipate to specify two NICs for creating > bonding device > (one plugged and one virtual NIC) in XML. here we can specify > the NIC's mac addresses > in XML, which could facilitate qemu-guest-agent to find the > network interfaces in guest. > > - when boot VM, we monitor the qemu-guest-agent process in guest > OS that > when qemu-guest-agent is available, sending command to > qemu-guest-agent to > let it create the bonding device at once according to the XML > configuration. > here netcf maybe a good tool to create bonding device easily. If I understand correctly, in your scenario, bonding device (bondX) is created by qemu-guest agent dynamicaly at every boot time. Is that right ? If so, I think it's hard for a guest administrator to configure bonding device (such as IP address). How about creating configuration file like /etc/sysconfig/network-scripts/ifcfg-bond0 (in Red Hat environment) to persistent boinding device ? > - if need to do migration, checking the bonding's virtual NIC > whether able to > access the plugged NIC's LAN. otherwise, when the passthroughed > NIC is unplugged, > the network would be broken. I think this check should be done before enslaving each NIC. By the way, how do you check whether both NICs are connected to the same network segment? I wonder if it's difficult ... > - during migration, unplug the passthroughed NIC. then do native > magration. > > - on destination side, check whether need to hotplug new NIC > according to XML. > then hotplug the deivce according the source node in XML, tell > qemu-guest-agent > to switch the hotplugged NIC activities. > > Thanks, > Chen Sincrely, Taku Izumi

1 0

[libvirt] [RFC PATCH 00/12] qemu: add support to hot-plug/unplug cpu device
by Zhu Guihua 23 Jan '15

23 Jan '15

If you apply the folowing patchset [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg01552.html, and [PATCH v2 00/11] cpu: add i386 cpu hot remove support https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg01557.html, qemu can support hotplug and hot-unplug cpu device. So this patch series will make libvirt support hotplug and hot-unplug cpu device for qemu driver, and now only supports one cpu driver which is 'qemu64-x86_64-cpu'. The cpu device's xml like this: <cpu driver='qemu64-x86_64-cpu' apic_id='3'> Zhu Guihua (12): domain_conf: allocate cpu's apic id dynamically domain_conf: add support for cpu device configuration in XML domain_conf: introduce cpu def helpers domain_conf: introduce cpu device hotplug helpers qemu_driver: implement cpu device hotplug on config level qemu_command: introduce a func for cpu device alias assignment qemu: implement support for qemu64-x86_64-cpu qemu: introduce qemuBuildCPUDeviceStr qemu: implement cpu device hotplug on live level qemu: implement cpu device hotunplug on live level qemu_monitor_json: sort JSON array of cpu info qemu_driver: detect threads corresponding to Vcpus src/conf/domain_conf.c | 188 +++++++++++++++++++++++++++ src/conf/domain_conf.h | 35 +++++ src/libvirt_private.syms | 6 + src/qemu/qemu_capabilities.c | 3 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 83 +++++++++++- src/qemu/qemu_command.h | 8 ++ src/qemu/qemu_driver.c | 296 ++++++++++++++++++++++++------------------- src/qemu/qemu_driver.h | 8 ++ src/qemu/qemu_hotplug.c | 129 +++++++++++++++++++ src/qemu/qemu_hotplug.h | 11 ++ src/qemu/qemu_monitor_json.c | 31 ++++- src/util/virbitmap.c | 2 +- src/util/virbitmap.h | 2 + 14 files changed, 668 insertions(+), 135 deletions(-) -- 1.9.3

3 37

[libvirt] LSN-2015-0001: CVE-2015-0236 snapshots and save images leak VNC passwords
by Eric Blake 22 Jan '15

22 Jan '15

Libvirt Security Notice: LSN-2015-0001 ====================================== Summary: snapshots and save images leak VNC passwords Reported on: 20150120 Published on: 20150122 Fixed on: 20150122 Reported by: Luyao Huang <lhuang(a)redhat.com> Patched by: Peter Krempa <pkrempa(a)redhat.com> See also: CVE-2015-0236 Description ----------- The two interfaces virDomainSnapshotGetXMLDesc and virDomainSaveImageGetXMLDesc would accept the VIR_DOMAIN_XML_SECURE flag in situations where virDomainGetXMLDesc did not, when fine-grained access control lists (ACL) are in use. As a result, a client can use a snapshot or save image to bypass restrictions and gain access to the secured information. Impact ------ A client using a read-write connection, and which has the 'domain:read' ACL privilege while lacking 'domain:secure_read', can trigger an information leak of data by using VIR_DOMAIN_XML_SECURE with the affected interfaces. Fortunately, the only data in this category is the value of an optional VNC password. Workaround ---------- VNC passwords are notoriously weak (they are capped at an 8 byte maximum length; the VNC protocol sends them in plaintext over the network; and FIPS mode execution prohibits the use of a VNC password), so it is recommended that users not create domains with a VNC password in the first place. Domains that do not use VNC passwords do not suffer from information leaks; the use of SPICE connections is recommended not only because it avoids the leak, but also because SPICE provides better features than VNC for a guest graphics device. Furthermore, the leak is only possible when fine-grained ACLs are in use; read-only clients cannot trigger the issue. Therefore, the problem is avoided if no user is granted the 'read' ACL privilege without also having the 'read_secure' privilege. Another mitigation is that the information leak can only occur if a snapshot or save image exists; a user that is denied 'read_secure' is typically also unable to create such an image, so the leak depends on a more privileged user making use of that feature. 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 Fixed in: v1.2.12 Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: 03c3c0c874c84dfa51ef17556062b095c6e1c0a3 Fixed by: b1674ad5a97441b7e1bd5f5ebaff498ef2fbb11b Branch: v1.1.0-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: a976724f9a10730e1339628482a283653efdb72c Fixed by: c4c824ec818ce85de049ed5546fa8ce3c8b76e32 Branch: v1.1.1-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: 9a2728e1b28b67a682e55d8dd3c0d79e21f0ad37 Fixed by: 2c6fc46d987911e310d30621cd6fc195af102fee Branch: v1.1.2-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: 6eec2b830a752c95fc2d971d3daf7626f9701290 Fixed by: 947c969fc248c2324e565b5e4f80a3d11733f12b 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 by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: ca840e9c827fefadae2e00875b4a552b990b959f Fixed by: 76d6cc3f24ab545694e77e2eafa981d861b965a4 Branch: v1.1.4-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: 43d16684c2018c20db1fba35542eb1d52ecb8d7a Fixed by: 17defce9159c5111e7011e575ba72803a9418086 Branch: v1.2.0-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: 9475a25c86f3748e2069af67db69d79864b707b9 Fixed by: 8abca887b19600b6652654a01a78455afd4d8294 Branch: v1.2.1-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: f7c70c20530954c2c1a2ce0d192d01a8f71c0093 Fixed by: 1f348188e0698ef2535c81d5a779189531c5df99 Branch: v1.2.2-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: e99c25ca63c695a63b4c9b91ee956be4fb660772 Fixed by: 8107c1e3694ba4685960ec09868076379718f037 Branch: v1.2.3-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: 4edae3cb9600132e875a5b97cf31089a6c8f4cb2 Fixed by: 94d18e8f6dbe3afdc72b6df13e3eaa8861874a14 Branch: v1.2.4-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: d406f0858e7e3a6199788d3c64217c69d7702032 Fixed by: 4700507a484aec43b02724893cbed931e52f86e0 Branch: v1.2.5-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: b0b5e885f05a80d63e8a457031ea884e867244ad Fixed by: 6b78ba5a15fb1077cee88cc30f1e5ba16485cd83 Branch: v1.2.6-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: 9b056d8daf68b6357ca05adbfddb53a85d077a1d Fixed by: b87f3f835a5c88625d9514aae9a2ddf30bc64319 Branch: v1.2.7-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: cc0cc987a53f5e3825c7d972e219e08688d4480b Fixed by: aeb505814531d505f4d7718a10a96dd6dea14457 Branch: v1.2.8-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: c0f3e664a68509a3d842bdc3fd126257da46d0c0 Fixed by: cef411296b2513ffd80dbf9cab1f54bd0c68fe6a Branch: v1.2.9-maint Broken in: v1.2.9.1 Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: 19f8fec02d9b0a8de877d872c5b59597bd878a8d Fixed by: 295f3c88ce71b8e83a489cb0d48431e124c12081 Branch: v1.2.10-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: c379b17e259db4f07843c2a7a883fda1a1bd043f Fixed by: d6e10847e0cd2bd7fc1824ad65fe859987715881 Branch: v1.2.11-maint Broken by: e341435e5090677c67a0d3d4ca0393102054841f Fixed by: 41358b7e91a20c9a89b03202b8c4139f92dd1953 Fixed by: 7195a5fa4718d915b28bb6e3380255eb1fbf994a -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

1 0

[libvirt] nodeinfo test cases for x86_64 AMD CPUs
by Steffen Persvold 22 Jan '15

22 Jan '15

Hi, Lately we’ve been puzzled by the nodeinfo returned for AMD 63xx based platforms so I checked out libvirt from Git and checked out the testcases in test/nodeinfodata. Currently you have 3 AMD test cases there : linux-x86_64-test3 : AMD 6172 2.1 GHz (MCM, 12 cores per package/socket, 2 numa nodes per package/socket, 1 thread/core) 4 Sockets, 8 NUMA nodes, 48 CPU cores total. linux-x86_64-test7 : AMD 6174 2.2 GHz (MCM, 12 cores per package/socket, 2 numa nodes per package/socket, 1 thread/core) 2 Sockets, 4 NUMA nodes, 24 CPU cores total. linux-x86_64-test8 : AMD 6282 SE 2.6 GHz (MCM, 8 CU(core) per package/socket, 2 numa nodes per package/socket, 2 threads/CU(core)) 4 Sockets, 8 NUMA nodes, 64 CPU cores total. However, the “expected” output from each of these are wrong I believe : % ~/libvirt/tests/nodeinfodata$ cat linux-x86_64-test{3,7,8}.expected CPUs: 48/48, MHz: 2100, Nodes: 8, Sockets: 1, Cores: 6, Threads: 1 CPUs: 24/24, MHz: 2200, Nodes: 1, Sockets: 1, Cores: 24, Threads: 1 CPUs: 64/64, MHz: 2593, Nodes: 1, Sockets: 1, Cores: 64, Threads: 1 In my opinion it should have been : CPUs: 48/48, MHz: 2100, Nodes: 8, Sockets: 4, Cores: 12, Threads: 1 CPUs: 24/24, MHz: 2200, Nodes: 4, Sockets: 2, Cores: 12, Threads: 1 CPUs: 64/64, MHz: 2593, Nodes: 8, Sockets: 4, Cores: 8, Threads: 2 Atleast that’s more in line with what tools like “lscpu” and “lstopo” would report. For example, I have a dual-socket AMD 6376 based system. lscpu reports : $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0-31 Thread(s) per core: 2 Core(s) per socket: 8 Socket(s): 2 NUMA node(s): 4 Vendor ID: AuthenticAMD CPU family: 21 Model: 2 Stepping: 0 CPU MHz: 2299.820 BogoMIPS: 4600.03 Virtualization: AMD-V L1d cache: 16K L1i cache: 64K L2 cache: 2048K L3 cache: 6144K NUMA node0 CPU(s): 0-7 NUMA node1 CPU(s): 8-15 NUMA node2 CPU(s): 16-23 NUMA node3 CPU(s): 24-31 virsh nodeinfo however : CPU model: x86_64 CPU(s): 32 CPU frequency: 2299 MHz CPU socket(s): 1 Core(s) per socket: 32 Thread(s) per core: 1 NUMA cell(s): 1 Memory size: 49448656 KiB Looking more closely at the code in src/nodeinfo.c:linuxNodeInfoCPUPopulate() I believe it makes some false assumptions. When iterating over the NUMA nodes, it expects that NUMA nodes can contain more than one socket, whereas on AMD systems atleast it’s the other way around (Sockets can contain more than 1 socket). Hence, the topology check at the end goes all wrong and libvirt uses just a flat topology : if ((nodeinfo->nodes * nodeinfo->sockets * nodeinfo->cores * nodeinfo->threads) != (nodeinfo->cpus + offline)) { nodeinfo->nodes = 1; nodeinfo->sockets = 1; nodeinfo->cores = nodeinfo->cpus + offline; nodeinfo->threads = 1; } If instead the “fallback” mechanism is used, which iterates over /sys/devices/system/cpu/cpu%d and finds sockets/cores/threads is used, *and* you leave nodeinfo->nodes out of the equation then it all makes sense. Iterating over entries in /sys/devices/system/node/node%d would then only be used to find nodeinfo->nodes. I have limited insight into how this would work on say an S390 system, so if my assumptions here are completely wrong please do tell :) Cheers, -- Steffen Persvold Chief Architect NumaChip, Numascale AS Tel: +47 23 16 71 88 Fax: +47 23 16 71 80 Skype: spersvold

1 1

[libvirt] (no subject)
by akrowiak＠linux.vnet.ibm.com 22 Jan '15

22 Jan '15

From: Tony Krowiak <akrowiak(a)linux.vnet.ibm.com> This patch set provides the code to synchonize some macvtap device modes when the values are changed on the guest's network device. The following modes will by synchronized: * PROMISC * MULTICAST * ALLMULTI I noticed something while testing this patch set that did not occur prior to installing more recent kernel and Qemu distributions. It seems that the VLAN table always has an entry for VLAN ID 0 when the rxfilter is queried during processing of the NIC_RX_FILTER_CHANGED event. That means that the PROMISC flag for macvtap0 will be set. I don't know if this will cause problems, but I thought I'd make note of it in case anybody wants to comment on that. Tony Krowiak (2): util: Functions for getting/setting device options qemu: change macvtap device options in response to NIC_RX_FILTER_CHANGED

1 4

[libvirt] [PATCH 0/2] fix two issues found by clang
by Pavel Hrdina 22 Jan '15

22 Jan '15

Pavel Hrdina (2): xenapi_driver: fix copy-paste typo esx_vi: fix possible segfault src/esx/esx_vi.c | 3 ++- src/xenapi/xenapi_driver.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) -- 2.0.5

2 6