- Devel - libvirt List Archives

[libvirt] [PATCH v7 0/9] x86: Secure Encrypted Virtualization (AMD)
by Brijesh Singh 06 Jun '18

06 Jun '18

This patch series provides support for launching an encrypted guest using AMD's new Secure Encrypted Virtualization (SEV) feature. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV feature allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest VM. At very high level the flow looks this: 1. mgmt tool calls virConnectGetDomainCapabilities. This returns an XML document that includes the following <feature> ... <sev supported='yes'> <cbitpos> </cbitpos> <reduced-phys-bits> </reduced-phys-bits> </sev> </feature> If <sev> is provided then we indicate that hypervisor is capable of launching SEV guest. mgmt tool can call virNodeGetSEVCapabilities() to get the additional informations like PDH and certificate chain etc. 2. (optional) mgmt tool can provide the PDH and Cert-chain to guest owner in case if guest owner wish to establish a secure connection with SEV firmware to negotiate a key used for validating the measurement. 3. mgmt tool requests to start a guest calling virCreateXML(), passing \ VIR_DOMAIN_START_PAUSED. The xml would include <launch-security type='sev'> <cbitpos>47</cbitpos> <reduced-phys-bits>1</reduced-phys-bits> <policy>0x1</policy> (optional) <dh-cert> </dh-cert> /* Guest owners Diffie-Hellman key */ <session> </session> /* Guest owners Session blob */ </launch-security> 4. Libvirt generate the QEMU cli arg to enable the SEV feature, a typical args looks like this: # $QEMU .. -machine memory-encryption=sev0 \ -object sev-guest,id=sev0,dh-cert-file=<file>.... 5. Libvirt generates lifecycle VIR_DOMAIN_EVENT_SUSPENDED_PAUSED event 6. mgmt tool gets the VIR_DOMAIN_EVENT_SUSPENDED_PAUSED and calls virDomainGetLaunchSecretInfo() to retrieve the measurement of encrypted memory. 7. (optional) mgmt tool can provide the measurement value to guest owner, which can validate the measurement and gives GO/NO-GO answer. If mgmt tool gets GO then it resumes the guest otherwise it calls destroy() to kill the guest. 8. mgmt tool resumes the guest TODO: * SEV guest require to use DMA apis for the virtio devices. In order to use the DMA apis the virtio devices must have this tag <driver iommu=on ats=on> It is a bit unclear to me where these changes need to go. Do we need to modify the libvirt to automatically add these when SEV is enabled or we ask mgmt tool to make sure that it creates XML with right tag to enable the DMA APIs for virtio devices. I am looking for some suggestions. Using these patches we have succesfully booted and tested a guest both with and without SEV enabled. SEV Firmware API spec is available at: https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf Changes since v6: * add API to get SEV PDH and Certificate chain data * drop virsh command changes. We can revisit this later when we have more visibility on setter. Change since v5: * drop the seperate test patch and merge the code with other patches. * rename the xml from sev -> launch-security-sev * make policy field mandatory * address multiple feedback from previous reviews. Changes since v4: * add /dev/sev in shared device list Changes since v3: * rename QEMU_CAPS_SEV -> QEMU_CAPS_SEV_GUEST * update caps_2.12.0.x86_64.replies to include query-sev-capabilities data Changes since v2: * make cbitpos, policy and reduced-phys-bits as unsigned int * update virDomainGetLaunchSecurityInfo to accept virTypedParameterPtr *params instead of virTypedParameterPtr params. Changes since v1: * rename <sev> -> <launch-security> for domain * add more information about policy and other fields in domaincaps.html * split the domain_conf support in two patches * add virDomainGetLaunchInfo() to retrieve the SEV measurement * extend virsh command to show the domain's launch security information * add test cases to validate newly added <launch-security> element * fix issues reported with 'make check' and 'make syntax-check' The complete git tree is available at: https://github.com/codomania/libvirt/tree/v7 Brijesh Singh (9): qemu: provide support to query the SEV capability conf: expose SEV feature in domain capabilities libvirt-host: expose virNodeGetSEVCapability API conf: introduce launch-security element in domain qemu/cgroup: add /dev/sev in shared devices list qemu: add support to launch SEV guest libvirt: add new public API to get launch security info remote: implement the remote protocol for launch security qemu: Add support to launch security info docs/drvqemu.html.in | 1 + docs/formatdomain.html.in | 115 +++++++++++++++ docs/formatdomaincaps.html.in | 30 ++++ docs/schemas/domaincaps.rng | 14 ++ docs/schemas/domaincommon.rng | 37 +++++ include/libvirt/libvirt-domain.h | 17 +++ include/libvirt/libvirt-host.h | 42 ++++++ src/conf/domain_capabilities.c | 31 +++- src/conf/domain_capabilities.h | 17 +++ src/conf/domain_conf.c | 133 +++++++++++++++++ src/conf/domain_conf.h | 27 ++++ src/driver-hypervisor.h | 14 ++ src/libvirt-domain.c | 48 +++++++ src/libvirt-host.c | 48 +++++++ src/libvirt_private.syms | 2 +- src/libvirt_public.syms | 6 + src/qemu/qemu.conf | 2 +- src/qemu/qemu_capabilities.c | 90 +++++++++++- src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_capspriv.h | 4 + src/qemu/qemu_cgroup.c | 2 +- src/qemu/qemu_command.c | 41 ++++++ src/qemu/qemu_driver.c | 160 +++++++++++++++++++++ src/qemu/qemu_monitor.c | 18 +++ src/qemu/qemu_monitor.h | 6 + src/qemu/qemu_monitor_json.c | 121 ++++++++++++++++ src/qemu/qemu_monitor_json.h | 5 + src/qemu/qemu_process.c | 62 ++++++++ src/qemu/test_libvirtd_qemu.aug.in | 1 + src/remote/remote_daemon_dispatch.c | 91 ++++++++++++ src/remote/remote_driver.c | 81 +++++++++++ src/remote/remote_protocol.x | 39 ++++- src/remote_protocol-structs | 24 ++++ tests/genericxml2xmlindata/launch-security-sev.xml | 24 ++++ tests/genericxml2xmltest.c | 2 + .../caps_2.12.0.x86_64.replies | 10 ++ tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 3 +- tests/qemuxml2argvdata/launch-security-sev.args | 29 ++++ tests/qemuxml2argvdata/launch-security-sev.xml | 37 +++++ tests/qemuxml2argvtest.c | 4 + 40 files changed, 1435 insertions(+), 7 deletions(-) create mode 100644 tests/genericxml2xmlindata/launch-security-sev.xml create mode 100644 tests/qemuxml2argvdata/launch-security-sev.args create mode 100644 tests/qemuxml2argvdata/launch-security-sev.xml -- 2.7.4

2 13

[libvirt] [PATCH] fdstream: Report error from the I/O thread
by John Ferlan 06 Jun '18

06 Jun '18

https://bugzilla.redhat.com/show_bug.cgi?id=1529059 Commit id 0fe4aa14 added the thread specific error message reporting (or save) to virFDStreamEvent; however, as processing goes via virStream{Send|SendHole|Recv} via calls from daemonStreamHandle{WriteData|Hole|Read} the last error gets reset in the main libvirt API's thus, whatever error may have been set as last error will be cleared prior to the error paths using it resulting in the generic error on the client side. For each of the paths that check threadQuit or threadErr, check if threadErr was set and set it agian if there isn't a last error (e.g. some other failure) set so that the message can be provided back to the client. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/util/virfdstream.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/src/util/virfdstream.c b/src/util/virfdstream.c index e4973a2bd0..8189559964 100644 --- a/src/util/virfdstream.c +++ b/src/util/virfdstream.c @@ -795,8 +795,13 @@ static int virFDStreamWrite(virStreamPtr st, const char *bytes, size_t nbytes) char *buf; if (fdst->threadQuit || fdst->threadErr) { - virReportSystemError(EBADF, "%s", - _("cannot write to stream")); + + /* virStreamSend will virResetLastError possibly set + * by virFDStreamEvent */ + if (fdst->threadErr && !virGetLastError()) + virSetError(fdst->threadErr); + else + virReportSystemError(EBADF, "%s", _("cannot write to stream")); goto cleanup; } @@ -875,8 +880,13 @@ static int virFDStreamRead(virStreamPtr st, char *bytes, size_t nbytes) while (!(msg = fdst->msg)) { if (fdst->threadQuit || fdst->threadErr) { if (nbytes) { - virReportSystemError(EBADF, "%s", - _("stream is not open")); + /* virStreamRecv will virResetLastError possibly set + * by virFDStreamEvent */ + if (fdst->threadErr && !virGetLastError()) + virSetError(fdst->threadErr); + else + virReportSystemError(EBADF, "%s", + _("stream is not open")); } else { ret = 0; } @@ -976,8 +986,12 @@ virFDStreamSendHole(virStreamPtr st, * might mess up file position for the thread. */ if (fdst->threadQuit || fdst->threadErr) { - virReportSystemError(EBADF, "%s", - _("stream is not open")); + /* virStreamSendHole will virResetLastError possibly set + * by virFDStreamEvent */ + if (fdst->threadErr && !virGetLastError()) + virSetError(fdst->threadErr); + else + virReportSystemError(EBADF, "%s", _("stream is not open")); goto cleanup; } -- 2.14.4

2 1

[libvirt] [PATCH 0/2] qemu: Fix memleak in qemuBuildNumaArgStr
by Michal Privoznik 06 Jun '18

06 Jun '18

*** BLURB HERE *** Michal Privoznik (2): qemu: Fix memleak in qemuBuildNumaArgStr qemuBuildNumaArgStr: Simplify @nodeBackends src/qemu/qemu_command.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) -- 2.16.4

2 3

[libvirt] [PATCH] virQEMUCapsFreeHostCPUModel: Don't always free host cpuData
by Michal Privoznik 06 Jun '18

06 Jun '18

This function exists because of 5276ec712a44b36. But it is missing initial check just like virQEMUCapsInitHostCPUModel() has. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_capabilities.c | 4 ++++ src/qemu/qemu_capspriv.h | 1 + tests/qemuxml2argvtest.c | 6 ++++-- 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 26969ed3dc..949c32ddd2 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -2846,10 +2846,14 @@ virQEMUCapsNewHostCPUModel(void) void virQEMUCapsFreeHostCPUModel(virQEMUCapsPtr qemuCaps, + virArch hostArch, virDomainVirtType type) { virQEMUCapsHostCPUDataPtr cpuData = virQEMUCapsGetHostCPUData(qemuCaps, type); + if (!virQEMUCapsGuestIsNative(hostArch, qemuCaps->arch)) + return; + virQEMUCapsHostCPUDataClearModels(cpuData); } diff --git a/src/qemu/qemu_capspriv.h b/src/qemu/qemu_capspriv.h index fea039ef3a..989d183c6c 100644 --- a/src/qemu/qemu_capspriv.h +++ b/src/qemu/qemu_capspriv.h @@ -58,6 +58,7 @@ virQEMUCapsSetArch(virQEMUCapsPtr qemuCaps, void virQEMUCapsFreeHostCPUModel(virQEMUCapsPtr qemuCaps, + virArch hostArch, virDomainVirtType type); void diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 14a994523f..4984028d38 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -388,8 +388,10 @@ testUpdateQEMUCaps(const struct testInfo *info, if (testAddCPUModels(info->qemuCaps, info->skipLegacyCPUs) < 0) goto cleanup; - virQEMUCapsFreeHostCPUModel(info->qemuCaps, VIR_DOMAIN_VIRT_KVM); - virQEMUCapsFreeHostCPUModel(info->qemuCaps, VIR_DOMAIN_VIRT_QEMU); + virQEMUCapsFreeHostCPUModel(info->qemuCaps, caps->host.arch, + VIR_DOMAIN_VIRT_KVM); + virQEMUCapsFreeHostCPUModel(info->qemuCaps, caps->host.arch, + VIR_DOMAIN_VIRT_QEMU); virQEMUCapsInitHostCPUModel(info->qemuCaps, caps->host.arch, VIR_DOMAIN_VIRT_KVM); -- 2.16.4

2 1

[libvirt] [ v3 0/4] Introduce network-backed loader & NVRAM.
by Prerna Saxena 06 Jun '18

06 Jun '18

Libvirt domain XML allows only local filepaths to specify a loader element or its matching NVRAM. Given that VMs may themselves move across hypervisor hosts, it should be possible to allocate loaders/NVRAM disks on network storage for uninterrupted access. This series extends the loader & NVRAM disk elements to be described as virStorageSource* elements, as discussed in : https://www.redhat.com/archives/libvir-list/2018-March/msg01721.html Sample XML with new annotation: <loader readonly='yes' type='pflash' backing='file'> <source file='/usr/share/OVMF/OVMF_CODE.fd'/> </loader> <nvram backing='network'> <source protocol='iscsi' name='iqn.2013-07.com.example:iscsi-nopool/0'> <host name='example.com' port='6000'/> </source> </nvram> References: ---------- v0/ Proposal: https://www.redhat.com/archives/libvir-list/2018-March/msg01721.html.v1 v1: https://www.redhat.com/archives/libvir-list/2018-April/msg02024.html v2: https://www.redhat.com/archives/libvir-list/2018-May/msg00948.html Changelog: --------- Changes since v2: - Consolidated patches with related data structures to avoid build breakage. - Passes make check & make syntax-check. Prerna Saxena (4): Schema: Introduce XML schema for network-backed loader and nvram elements. Loader: Add a more elaborate definition. Test: Add a test snippet to evaluate command line generation for loader/nvram specified via virStorageSource Documentation: Add a blurb for the newly added XML snippets for loader and nvram. docs/formatdomain.html.in | 36 +++- docs/schemas/domaincommon.rng | 108 +++++++++-- src/bhyve/bhyve_command.c | 6 +- src/conf/domain_conf.c | 250 +++++++++++++++++++++++-- src/conf/domain_conf.h | 11 +- src/qemu/qemu_cgroup.c | 13 +- src/qemu/qemu_command.c | 21 ++- src/qemu/qemu_domain.c | 31 ++- src/qemu/qemu_driver.c | 7 +- src/qemu/qemu_parse_command.c | 30 ++- src/qemu/qemu_process.c | 54 ++++-- src/security/security_dac.c | 6 +- src/security/security_selinux.c | 6 +- src/security/virt-aa-helper.c | 14 +- src/vbox/vbox_common.c | 11 +- src/xenapi/xenapi_driver.c | 4 +- src/xenconfig/xen_sxpr.c | 19 +- src/xenconfig/xen_xm.c | 9 +- tests/qemuxml2argvdata/bios-nvram-network.args | 31 +++ tests/qemuxml2argvdata/bios-nvram-network.xml | 42 +++++ tests/qemuxml2argvtest.c | 1 + 21 files changed, 606 insertions(+), 104 deletions(-) create mode 100644 tests/qemuxml2argvdata/bios-nvram-network.args create mode 100644 tests/qemuxml2argvdata/bios-nvram-network.xml -- 1.8.1.2

3 8

[libvirt] [PATCH] qemu: Honour <on_reboot/>
by Michal Privoznik 06 Jun '18

06 Jun '18

https://bugzilla.redhat.com/show_bug.cgi?id=1476866 For some reason, we completely ignore <on_reboot/> setting for domains. The implementation is simply not there. It never was. However, things are slightly more complicated. QEMU sends us two RESET events on domain reboot. Fortunately, the event contains this 'guest' field telling us who initiated the reboot. And since we don't want to destroy the domain if the reset is initiated by a user, we have to ignore those events. Whatever, just look at the code. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_monitor.c | 4 ++-- src/qemu/qemu_monitor.h | 3 ++- src/qemu/qemu_monitor_json.c | 8 +++++++- src/qemu/qemu_process.c | 34 ++++++++++++++++++++++++++++++---- 5 files changed, 42 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 4c9050aff..d865e67c7 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -233,6 +233,7 @@ struct _qemuDomainObjPrivate { bool agentError; bool gotShutdown; + bool gotReset; bool beingDestroyed; char *pidfile; diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 19082d8bf..8f81a2b28 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -1344,12 +1344,12 @@ qemuMonitorEmitShutdown(qemuMonitorPtr mon, virTristateBool guest) int -qemuMonitorEmitReset(qemuMonitorPtr mon) +qemuMonitorEmitReset(qemuMonitorPtr mon, virTristateBool guest) { int ret = -1; VIR_DEBUG("mon=%p", mon); - QEMU_MONITOR_CALLBACK(mon, ret, domainReset, mon->vm); + QEMU_MONITOR_CALLBACK(mon, ret, domainReset, mon->vm, guest); return ret; } diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index 31f7e97ba..8c33f6783 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -134,6 +134,7 @@ typedef int (*qemuMonitorDomainShutdownCallback)(qemuMonitorPtr mon, void *opaque); typedef int (*qemuMonitorDomainResetCallback)(qemuMonitorPtr mon, virDomainObjPtr vm, + virTristateBool guest, void *opaque); typedef int (*qemuMonitorDomainPowerdownCallback)(qemuMonitorPtr mon, virDomainObjPtr vm, @@ -346,7 +347,7 @@ int qemuMonitorEmitEvent(qemuMonitorPtr mon, const char *event, long long seconds, unsigned int micros, const char *details); int qemuMonitorEmitShutdown(qemuMonitorPtr mon, virTristateBool guest); -int qemuMonitorEmitReset(qemuMonitorPtr mon); +int qemuMonitorEmitReset(qemuMonitorPtr mon, virTristateBool guest); int qemuMonitorEmitPowerdown(qemuMonitorPtr mon); int qemuMonitorEmitStop(qemuMonitorPtr mon); int qemuMonitorEmitResume(qemuMonitorPtr mon); diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index b8a68154a..8a1501ced 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -536,7 +536,13 @@ static void qemuMonitorJSONHandleShutdown(qemuMonitorPtr mon, virJSONValuePtr da static void qemuMonitorJSONHandleReset(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED) { - qemuMonitorEmitReset(mon); + bool guest = false; + virTristateBool guest_initiated = VIR_TRISTATE_BOOL_ABSENT; + + if (data && virJSONValueObjectGetBoolean(data, "guest", &guest) == 0) + guest_initiated = guest ? VIR_TRISTATE_BOOL_YES : VIR_TRISTATE_BOOL_NO; + + qemuMonitorEmitReset(mon, guest_initiated); } static void qemuMonitorJSONHandlePowerdown(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 0aecce3b1..889efc7f0 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -478,27 +478,51 @@ qemuProcessFindVolumeQcowPassphrase(qemuMonitorPtr mon ATTRIBUTE_UNUSED, static int qemuProcessHandleReset(qemuMonitorPtr mon ATTRIBUTE_UNUSED, virDomainObjPtr vm, + virTristateBool guest_initiated, void *opaque) { virQEMUDriverPtr driver = opaque; - virObjectEventPtr event; + virObjectEventPtr event = NULL; qemuDomainObjPrivatePtr priv; virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); + bool callOnReboot = false; virObjectLock(vm); + priv = vm->privateData; + + /* This is a bit tricky. When a guest does 'reboot' we receive RESET event + * twice, both times it's guest initiated. However, if users call 'virsh + * reset' we still receive two events but the first one is guest_initiated + * = no, the second one is guest_initiated = yes. Therefore, to avoid + * executing onReboot action in the latter case we need this complicated + * construction. */ + if (guest_initiated == VIR_TRISTATE_BOOL_NO) { + VIR_DEBUG("Ignoring not guest initiated RESET event from domain %s", + vm->def->name); + priv->gotReset = true; + } else if (priv->gotReset && guest_initiated == VIR_TRISTATE_BOOL_YES) { + VIR_DEBUG("Ignoring second RESET event from domain %s", + vm->def->name); + priv->gotReset = false; + } else { + callOnReboot = true; + } + event = virDomainEventRebootNewFromObj(vm); - priv = vm->privateData; if (priv->agent) qemuAgentNotifyEvent(priv->agent, QEMU_AGENT_EVENT_RESET); if (virDomainSaveStatus(driver->xmlopt, cfg->stateDir, vm, driver->caps) < 0) VIR_WARN("Failed to save status on vm %s", vm->def->name); + if (callOnReboot && + guest_initiated == VIR_TRISTATE_BOOL_YES && + vm->def->onReboot == VIR_DOMAIN_LIFECYCLE_DESTROY) + qemuProcessShutdownOrReboot(driver, vm); + virObjectUnlock(vm); - qemuDomainEventQueue(driver, event); - virObjectUnref(cfg); return 0; } @@ -555,6 +579,7 @@ qemuProcessFakeReboot(void *opaque) goto endjob; } priv->gotShutdown = false; + priv->gotReset = false; event = virDomainEventLifecycleNewFromObj(vm, VIR_DOMAIN_EVENT_RESUMED, VIR_DOMAIN_EVENT_RESUMED_UNPAUSED); @@ -5320,6 +5345,7 @@ qemuProcessPrepareDomain(virConnectPtr conn, priv->monError = false; priv->monStart = 0; priv->gotShutdown = false; + priv->gotReset = false; VIR_DEBUG("Updating guest CPU definition"); if (qemuProcessUpdateGuestCPU(vm->def, priv->qemuCaps, caps, flags) < 0) -- 2.13.0

4 6

[libvirt] [RFC PATCH 0/6] qemu: Support pagesize tuning for pSeries guests
by Andrea Bolognani 06 Jun '18

06 Jun '18

The QEMU part, which is RFC as well, can be found at http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg02818.html Applies cleanly on top of c49013f26c6b40b741f4d5fc61269898f7fd25b8. Andrea Bolognani (6): conf: Reintroduce virDomainDef::hpt_resizing conf: Tweak HPT parsing and formatting qemu: Introduce QEMU_CAPS_MACHINE_PSERIES_CAP_HPT_MPS tests: Pretend we have pseries.cap-hpt-mps in 2.12 conf: Parse and format HPT maxpagesize qemu: Format pseries.cap-hpt-mps on the command line docs/schemas/domaincommon.rng | 21 +- src/conf/domain_conf.c | 72 ++++++- src/conf/domain_conf.h | 2 + src/qemu/qemu_capabilities.c | 8 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 57 ++++-- src/qemu/qemu_domain.c | 2 +- .../caps_2.12.0.aarch64.replies | 24 ++- .../caps_2.12.0.aarch64.xml | 2 +- .../caps_2.12.0.ppc64.replies | 180 +++++++++++++++++- .../caps_2.12.0.ppc64.xml | 3 +- .../caps_2.12.0.s390x.replies | 26 ++- .../caps_2.12.0.s390x.xml | 2 +- .../caps_2.12.0.x86_64.replies | 30 +-- .../caps_2.12.0.x86_64.xml | 2 +- tests/qemuxml2argvdata/pseries-features.args | 3 +- tests/qemuxml2argvdata/pseries-features.xml | 18 +- tests/qemuxml2argvtest.c | 1 + tests/qemuxml2xmloutdata/pseries-features.xml | 31 ++- tests/qemuxml2xmltest.c | 1 + 20 files changed, 401 insertions(+), 85 deletions(-) mode change 120000 => 100644 tests/qemuxml2xmloutdata/pseries-features.xml -- 2.17.0

3 22

[libvirt] [PATCH] qemu: fix msg could be a wild pointer in qemuMonitorIOProcess()
by Shannon Zhao 06 Jun '18

06 Jun '18

From: Weilun Zhu <zhuweilun(a)huawei.com> As qemuMonitorJSONIOProcess() will unlock the qemu monitor, there is some extreme situation, eg qemu send message to monitor twice in a short time, where the local viriable 'msg' of qemuMonitorIOProcess() could be a wild point: 1. qemuMonitorSend() assign mon->msg to parameter 'msg', which is alse a local variable of its caller qemuMonitorJSONCommandWithFd(), cause eventloop to send message to monitor, then wait condition. 2. qemu send message to monitor for the first time immediately. 3. qemuMonitorIOProcess() is called, then wake up the qemuMonitorSend() thread, but the qemuMonitorSend() thread stuck for a while, which means the qemu monitor is still unlocked. 4. qemu send message to monitor for the second time, such as RTC_CHANGE event 5. qemuMonitorIOProcess() is called, the local viriable 'msg' is assigned to mon->msg. 6. qemuMonitorIOProcess() call qemuMonitorJSONIOProcess() to deal with the message 7. qemuMonitorJSONIOProcess() unlock the qemu monitor, qemuMonitorSend() thread get the lock and free the mon->msg, assign mon->msg to NULL. so the local viriable 'msg' of qemuMonitorIOProcess() is a wild pointer now. AFAIK, it is not harmful to call again virCondBroadcast() while msg is a wild pointer, but just in case, we fix it in this patch. --- src/qemu/qemu_monitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 43f1d2f..464f200 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -454,7 +454,7 @@ qemuMonitorIOProcess(qemuMonitorPtr mon) #if DEBUG_IO VIR_DEBUG("Process done %d used %d", (int)mon->bufferOffset, len); #endif - if (msg && msg->finished) + if (msg && msg == mon->msg && msg->finished) virCondBroadcast(&mon->notify); return len; } -- 1.8.3.1

3 3

[libvirt] [PATCH] docs: document mandatory signoffs in governance.html
by Ján Tomko 06 Jun '18

06 Jun '18

Amend the paragraphs about no CLAs and implicit license agreements to mention mandatory Signed-off-by tags. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- This is duplicating information, but I did not find a reasonable way to link the numbered list in hacking.html without making it look ugly. Very probably due to my lack of trying. docs/governance.html.in | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/governance.html.in b/docs/governance.html.in index df5999c0f2..e9608f673c 100644 --- a/docs/governance.html.in +++ b/docs/governance.html.in @@ -141,13 +141,17 @@ than having the interest and ability to provide a contribution. The libvirt project does not require any "Contributor License Agreement" - to be signed prior to engagement with the community. + to be signed prior to engagement with the community. However for + contributing patches, providing a 'Signed-off-by' line with the + author's legal name and e-mail address to demonstrate agreement + and compliance with the <a href="https://developercertificate.org/"> + Developer Certificate of Origin</a> is required. - In making a contribution to the project, the community member is - implicitly stating that they accept the terms of the license under - which the work they are contributing to is distributed. They are + In making a non-patch contribution to the project, the community + member is implicitly stating that they accept the terms of the license + under which the work they are contributing to is distributed. They are also implicitly stating that they have the legal right to make the contribution, if doing so on behalf of a broader organization / company. Most of the project's code is distributed under the GNU -- 2.13.6

2 1

[libvirt] [PATCH] qemu: Fix double free in qemuDomainSecretAESClear
by John Ferlan 06 Jun '18

06 Jun '18

Commit id 02b031a4 added a secondary path from which the incoming @secinfo would not be free'd until the private data was freed in qemuDomainStorageSourcePrivateDispose. However, by doing this the original intention to free @*secinfo afterwards is lost and thus the pass by value of the secinfo->s.aes (or secinfo->s.plain for its method) results in not keeping the NULL setting in the various secret.{username|iv|ciphertext} fields upon return to qemuDomainSecretInfoClear and eventually will result in a double free at domain destroy: raise () abort () __libc_message () malloc_printerr () _int_free () virFree qemuDomainSecretAESClear qemuDomainSecretInfoClear qemuDomainSecretInfoFree qemuDomainStorageSourcePrivateDispose virObjectUnref virStorageSourceClear virStorageSourceFree virDomainDiskDefFree virDomainDefFree virDomainObjRemoveTransientDef qemuProcessStop qemuDomainDestroyFlags virDomainDestroy Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/qemu/qemu_domain.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) Domains w/ secrets weren't very happy when I went to destroy them today during testing... Fortunately issue is not in 4.4.0... I modified both Plain and AES just because it's probably best to avoid something like this in the future. diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index f135117a95..1fb1ef1deb 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -945,23 +945,23 @@ qemuDomainMasterKeyCreate(virDomainObjPtr vm) static void -qemuDomainSecretPlainClear(qemuDomainSecretPlain secret) +qemuDomainSecretPlainClear(qemuDomainSecretPlainPtr secret) { - VIR_FREE(secret.username); - VIR_DISPOSE_N(secret.secret, secret.secretlen); + VIR_FREE(secret->username); + VIR_DISPOSE_N(secret->secret, secret->secretlen); } static void -qemuDomainSecretAESClear(qemuDomainSecretAES secret, +qemuDomainSecretAESClear(qemuDomainSecretAESPtr secret, bool keepAlias) { if (!keepAlias) - VIR_FREE(secret.alias); + VIR_FREE(secret->alias); - VIR_FREE(secret.username); - VIR_FREE(secret.iv); - VIR_FREE(secret.ciphertext); + VIR_FREE(secret->username); + VIR_FREE(secret->iv); + VIR_FREE(secret->ciphertext); } @@ -974,11 +974,11 @@ qemuDomainSecretInfoClear(qemuDomainSecretInfoPtr secinfo, switch ((qemuDomainSecretInfoType) secinfo->type) { case VIR_DOMAIN_SECRET_INFO_TYPE_PLAIN: - qemuDomainSecretPlainClear(secinfo->s.plain); + qemuDomainSecretPlainClear(&secinfo->s.plain); break; case VIR_DOMAIN_SECRET_INFO_TYPE_AES: - qemuDomainSecretAESClear(secinfo->s.aes, keepAlias); + qemuDomainSecretAESClear(&secinfo->s.aes, keepAlias); break; case VIR_DOMAIN_SECRET_INFO_TYPE_LAST: -- 2.14.4

2 1