[libvirt] AMD SEV's /dev/sev permissions and probing QEMU for capabilities
by Erik Skultety
Hi,
this is a summary of a private discussion I've had with guys CC'd on this email
about finding a solution to [1] - basically, the default permissions on
/dev/sev (below) make it impossible to query for SEV platform capabilities,
since by default we run QEMU as qemu:qemu when probing for capabilities. It's
worth noting is that this is only relevant to probing, since for a proper QEMU
VM we create a mount namespace for the process and chown all the nodes (needs a
SEV fix though).
# ll /dev/sev
crw-------. 1 root root
I suggested either force running QEMU as root for probing (despite the obvious
security implications) or using namespaces for probing too. Dan argued that
this would have a significant perf impact and suggested we ask systemd to add a
global udev rule.
I proceeded with cloning [1] to systemd and creating an udev rule that I planned
on submitting to systemd upstream - the initial idea was to mimic /dev/kvm and
make it world accessible to which Brijesh from AMD expressed a concern that
regular users might deplete the resources (limit on the number of guests
allowed by the platform). But since the limit is claimed to be around 4, Dan
discouraged me to continue with restricting the udev rule to only the 'kvm'
group which Laszlo suggested earlier as the limit is so small that a malicious
QEMU could easily deplete this during probing. This fact also ruled out any
kind of ACL we could create dynamically. Instead, he suggested that we filter
out the kvm-capable QEMU and put only that one in the namespace without a
significant perf impact.
- my take on this is that there could potentially be more than a single
kvm-enabled QEMU and therefore we'd need to create more than just a
single namespace.
- I also argued that I can image that the same kind of DOS attack might be
possible from within the namespace, even if we created the /dev/sev node
only in SEV-enabled guests (which we currently don't). All of us have
agreed that allowing /dev/sev in the namespace for only SEV-enabled
guests is worth doing nonetheless.
In the meantime, Christophe went through the kernel code to verify how the SEV
resources are managed and what protection is currently in place to mitigate the
chance of a process easily depleting the limit on SEV guests. He found that
ASID, which determines the encryption key, is allocated from a single ASID
bitmap and essentially guarded by a single 'sev->active' flag.
So, in conclusion, we absolutely need input from Brijesh (AMD) whether there
was something more than the low limit on number of guests behind the default
permissions. Also, we'd like to get some details on how the limit is managed,
helping to assess the approaches mentioned above.
Thanks and please do share your ideas,
Erik
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1665400
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1561113
6 years, 2 months
[libvirt] [dockerfiles PATCH 0/3] refresh: Minor Python style tweaks
by Andrea Bolognani
These are basically the same tweaks that have recently been
applied to lcitool.
Andrea Bolognani (3):
refresh: Remove double space
refresh: Drop Error class
refresh: Move exception handling to Application.run()
refresh | 40 +++++++++++++++++-----------------------
1 file changed, 17 insertions(+), 23 deletions(-)
--
2.20.1
6 years, 2 months
[libvirt] [PATCH 0/4] qemu: hotplug: Clean up and fix disk device unplug (blockdev-add saga)
by Peter Krempa
Refactor checking of disk bus and type for disk unplug and fix checking
whether a virtio disk has a running block job by deleting the
almost-identical implementation specific to virtio disks.
Peter Krempa (4):
qemu: hotplug: Remove 'ret' variable in qemuDomainDetachDeviceDiskLive
qemu: hotplug: Use typecasted enum in qemuDomainDetachDeviceDiskLive
qemu: hotplug: Use switch statement for selecting disk bus function
qemu: hotplug: Merge virtio and non-virtio disk unplug code
src/qemu/qemu_hotplug.c | 87 ++++++++++++++++++-----------------------
1 file changed, 39 insertions(+), 48 deletions(-)
--
2.20.1
6 years, 2 months
[libvirt] [PATCH] snapshots: More clarification about REDEFINE
by Eric Blake
Based on recent list questions about the proposed addition of
virDomainCheckpointCreateXML(REDEFINE), it is worth adding some
clarification to the existing snapshot redefine documentation that is
serving as the basis for checkpoints.
Normal snapshot creation requires very few elements from the user XML
(libvirt can pick sane defaults for items that are omitted, and many
fields, including <domain> are documented as readonly output fields
ignored on input). But during REDEFINE, the API wants the complete XML
produced by an earlier virDomainSnapshotGetXMLDesc, which includes a
<domain> sub-element capturing the state a the time the snapshot was
first created. As the domain state has likely changed in the meantime,
omitting <domain> during REDEFINE is extremely risky (to the point
that virDomainSnapshotRevert() requires the use of FORCE flag to use
such a snapshot) - we only support it because of
backwards-compatibility to snapshots created before 0.9.5 started
capturing <domain>. When checkpoints are introduced, the <domain>
element will be mandatory in REDEFINE.
Note that because <domain> can be potentially huge, we also are unable
to include a bulk listing or redefine of all <domainsnapshot>s for a
single domain in one XML dump (for example, a 1M <domain> XML * 16
snapshots explodes into 16M in a bulk form, which gets difficult to
send over RPC). Perhaps we could add a flag to request that the
<domain> sub-element be omitted on output, but such output is no
longer suitable for sane REDEFINE input.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
Question: 0.9.5 is so long ago, is it worth reworking the qemu
snapshot code to declare that REDEFINE will no longer import a
snapshot definition that lacks a <domain> subelement? (Note: the vbox
driver also supports snapshots and the REDEFINE flag, but does not
output <domain> and thus should still allow it to be omitted on
redefine). The current API wording DOES have the disclaimer regarding
REDEFINE that "the hypervisor may validate that reverting to the
snapshot appears to be possible", which we can use as our escape
clause whereby the modern qemu driver is merely adding a validation
that <domain> must be present for the redefine to be viable, even
though it is at odds with our usual efforts to always parse XML that
used to work in earlier versions.
If we make my proposed followup change, and someone has kept a VM
definition with snapshots alive since libvirt pre-0.9.5, updating to
modern libvirt would lose their old snapshots. Then again, if your
guest has been around that long, do you REALLY want to revert to a
snapshot from that many years ago?
docs/formatsnapshot.html.in | 3 ++-
src/libvirt-domain-snapshot.c | 24 +++++++++++++++---------
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/docs/formatsnapshot.html.in b/docs/formatsnapshot.html.in
index c60b4fb7c9..99addc6675 100644
--- a/docs/formatsnapshot.html.in
+++ b/docs/formatsnapshot.html.in
@@ -79,7 +79,8 @@
redefining a snapshot (<span class="since">since 0.9.5</span>),
with the <code>VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE</code> flag
of <code>virDomainSnapshotCreateXML()</code>, all of the XML
- described here is relevant.
+ described here is relevant on input, even the fields that are
+ normally described as readonly for output.
</p>
<p>
Snapshots are maintained in a hierarchy. A domain can have a
diff --git a/src/libvirt-domain-snapshot.c b/src/libvirt-domain-snapshot.c
index 947547627a..be9bf71af9 100644
--- a/src/libvirt-domain-snapshot.c
+++ b/src/libvirt-domain-snapshot.c
@@ -117,15 +117,21 @@ virDomainSnapshotGetConnect(virDomainSnapshotPtr snapshot)
*
* If @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE, then this
* is a request to reinstate snapshot metadata that was previously
- * discarded, rather than creating a new snapshot. This can be used
- * to recreate a snapshot hierarchy on a destination, then remove it
- * on the source, in order to allow migration (since migration
- * normally fails if snapshot metadata still remains on the source
- * machine). When redefining snapshot metadata, the current snapshot
- * will not be altered unless the VIR_DOMAIN_SNAPSHOT_CREATE_CURRENT
- * flag is also present. It is an error to request the
- * VIR_DOMAIN_SNAPSHOT_CREATE_CURRENT flag without
- * VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE. On some hypervisors,
+ * captured from virDomainSnapshotGetXMLDesc() before removing that
+ * metadata, rather than creating a new snapshot. This can be used to
+ * recreate a snapshot hierarchy on a destination, then remove it on
+ * the source, in order to allow migration (since migration normally
+ * fails if snapshot metadata still remains on the source machine).
+ * Note that while original creation can omit a number of elements
+ * from @xmlDesc (and libvirt will supply sane defaults based on the
+ * domain state at that point in time), a redefinition must supply
+ * more elements (as the domain may have changed in the meantime, so
+ * that libvirt no longer has a way to resupply correct
+ * defaults). When redefining snapshot metadata, the domain's current
+ * snapshot will not be altered unless the
+ * VIR_DOMAIN_SNAPSHOT_CREATE_CURRENT flag is also present. It is an
+ * error to request the VIR_DOMAIN_SNAPSHOT_CREATE_CURRENT flag
+ * without VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE. On some hypervisors,
* redefining an existing snapshot can be used to alter host-specific
* portions of the domain XML to be used during revert (such as
* backing filenames associated with disk devices), but must not alter
--
2.20.1
6 years, 2 months
[libvirt] [PATCH] virobject: Improve documentation
by Eric Blake
I had to inspect the code to learn whether a final virObjectUnref()
calls ALL dispose callbacks in child-to-parent order (akin to C++
destructors), or whether I manually had to call a parent-class dispose
when writing a child class dispose method. The answer is the
former. (Thankfully, since VIR_FREE wipes out pointers for safety,
even if I had guessed wrong, I probably would not have tripped over a
double-free fault when the parent dispose ran for the second time).
While at it, the VIR_CLASS_NEW macro requires that the virObject
component at offset 0 be reached through the name 'parent', not
'object'.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
src/util/virobject.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/util/virobject.c b/src/util/virobject.c
index f08c18ce44..462b3d7d3f 100644
--- a/src/util/virobject.c
+++ b/src/util/virobject.c
@@ -147,10 +147,11 @@ virClassForObjectRWLockable(void)
*
* Register a new object class with @name. The @objectSize
* should give the total size of the object struct, which
- * is expected to have a 'virObject object;' field as its
- * first member. When the last reference on the object is
- * released, the @dispose callback will be invoked to free
- * memory of the object fields
+ * is expected to have a 'virObject parent;' field as (or
+ * contained in) its first member. When the last reference
+ * on the object is released, the @dispose callback will be
+ * invoked to free memory of the local object fields, as
+ * well as dispose callbacks of the parent classes
*
* Returns a new class instance
*/
--
2.20.1
6 years, 2 months
[libvirt] [jenkins-ci PATCH] lcitool: add special case for Debian i386/i686 mixup
by Daniel P. Berrangé
Although the toolchain binaries for 32-bit x86 are using the ABI
i686-linux-gnu, the library install directory is strangely named
with the different i386-linux-gnu.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
guests/lcitool | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/guests/lcitool b/guests/lcitool
index 76b2dc7..0f60704 100755
--- a/guests/lcitool
+++ b/guests/lcitool
@@ -101,6 +101,13 @@ class Util:
raise Exception("Unsupported architecture {}".format(native_arch))
return archmap[native_arch]
+ @staticmethod
+ def native_arch_to_lib(native_arch):
+ arch = Util.native_arch_to_abi(native_arch)
+ if arch == "i686-linux-gnu":
+ arch = "i386-linux-gnu"
+ return arch
+
@staticmethod
def native_arch_to_deb_arch(native_arch):
archmap = {
@@ -640,12 +647,14 @@ class Application:
if args.cross_arch:
deb_arch = Util.native_arch_to_deb_arch(args.cross_arch)
abi = Util.native_arch_to_abi(args.cross_arch)
+ lib = Util.native_arch_to_lib(args.cross_arch)
gcc = "gcc-" + abi
varmap["cross_arch"] = deb_arch
pkg_names = [p + ":" + deb_arch for p in cross_pkgs.values()]
pkg_names.append(gcc)
varmap["cross_pkgs"] = " \\\n ".join(sorted(set(pkg_names)))
varmap["cross_abi"] = abi
+ varmap["cross_lib"] = lib
sys.stdout.write(textwrap.dedent("""
RUN export DEBIAN_FRONTEND=noninteractive && \\
@@ -673,7 +682,7 @@ class Application:
ENV ABI "{cross_abi}"
ENV CONFIGURE_OPTS "--host={cross_abi} \\
--target={cross_abi}"
- ENV PKG_CONFIG_LIBDIR "/usr/lib/{cross_abi}/pkgconfig"
+ ENV PKG_CONFIG_LIBDIR "/usr/lib/{cross_lib}/pkgconfig"
""").format(**varmap))
elif package_format == "rpm":
if os_name == "Fedora" and os_version == "Rawhide":
--
2.20.1
6 years, 2 months
[libvirt] [PATCH v3 0/5] qemu_hotplug: Fix a rare race condition when detaching a device twice
by Michal Privoznik
v3 of:
https://www.redhat.com/archives/libvir-list/2019-March/msg00924.html
diff to v2:
- Dropped @enterMonitor from qemuDomainDeleteDevice,
- Simplified event checking since @vm is always locked after
@enterMonitor is dropped,
- Switched to plain qemuMonitorDelDevice for zpci device
- Added comment about error reporting to 3/5
Note that 3/5 was ACKed in v2.
Michal Prívozník (5):
qemu_hotplug: Introduce and use qemuDomainDeleteDevice
DO NOT APPLY: Simple reproducer
qemuMonitorJSONDelDevice: Return -2 on DeviceNotFound error
qemu_hotplug: Fix a rare race condition when detaching a device twice
DO NOT APPLY: Revert simple reproducer
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_hotplug.c | 278 +++++++++++++++--------------------
src/qemu/qemu_monitor.c | 10 ++
src/qemu/qemu_monitor_json.c | 5 +
4 files changed, 134 insertions(+), 160 deletions(-)
--
2.19.2
6 years, 2 months
[libvirt] [PATCH 0/3] Drop Upstart support
by Andrea Bolognani
Andrea Bolognani (3):
travis: Use 'redhat' init script on CentOS 7
Drop Upstart support
news: Document Upstart support being dropped
.travis.yml | 2 +-
docs/news.xml | 11 +++++++++
m4/virt-init-script.m4 | 7 +-----
src/Makefile.am | 29 -----------------------
src/remote/Makefile.inc.am | 2 --
src/remote/libvirtd.upstart | 47 -------------------------------------
6 files changed, 13 insertions(+), 85 deletions(-)
delete mode 100644 src/remote/libvirtd.upstart
--
2.20.1
6 years, 2 months
[libvirt] [PATCH v2 0/4] tools: console: a fix and improvment
by Nikolay Shirokovskiy
Jonh, I split the 1st patch the other way to avoid changing same
lines of code in subsequent patches.
Diff to v1[1]
- split 1st patch into 3
- change wordings of commit messages/error messages
- add minor changes to code as suggested by John
[1] https://www.redhat.com/archives/libvir-list/2019-February/msg00920.html
Nikolay Shirokovskiy (4):
tools: console: cleanup console on errors in main thread
tools: console: add missing locks in callbacks
tools: console: check if console was shutdown in callbacks
tools: console: pass stream/fd errors to user
tools/virsh-console.c | 224 ++++++++++++++++++++++++++++++++++++++------------
1 file changed, 171 insertions(+), 53 deletions(-)
--
1.8.3.1
6 years, 2 months
[libvirt] fix method delete() in src/main/java/org/libvirt/DomainSnapshot.java
by 傅姜晨
if VDSP is set to null during the method delete(), Object snapshot can't be freed in method free() in the same class.
Showing 1 changed file with 1 addition and 7 deletions.
View file
8 src/main/java/org/libvirt/DomainSnapshot.java
| | @@ -35,13 +35,7 @@ public DomainSnapshot(Connect virConnect, DomainSnapshotPointer VDSP) { |
| | | | * @throws LibvirtException |
| | | | */ |
| | | | publicintdelete(intflags) throwsLibvirtException { |
| | | | int success =0; |
| | | | if (VDSP!=null) { |
| | | | success = processError(libvirt.virDomainSnapshotDelete(VDSP, flags)); |
| | | | VDSP=null; |
| | | | } |
| | | |
|
| | | | return success; |
| | | | return processError(libvirt.virDomainSnapshotDelete(VDSP, flags)); |
| | | | } |
| | | |
|
| | | | @Override |
6 years, 2 months
