Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 16 11月, 2014 2 次提交
    • M
      util: Prepare URI formatting for libxml2 >= 2.9.2 · 3d021408
      由 Martin Kletzander 提交于 
      Since commit 8eb55d782a2b9afacc7938694891cc6fad7b42a5 libxml2 removes
two slashes from the URI when there is no server part.  This is fixed
with beb7281055dbf0ed4d041022a67c6c5cfd126f25, but only if the calling
application calls xmlSaveUri() on URI that xmlURIParse() parsed.  And
that is not the case in virURIFormat().  virURIFormat() accepts
virURIPtr that can be created without parsing it and we do that when we
format network storage paths for gluster for example.  Even though
virStorageSourceParseBackingURI() uses virURIParse(), it throws that data
structure right away.

Since we want to format URIs as URIs and not absolute URIs or opaque
URIs (see RFC 3986), we can specify that with a special hack thanks to
commit beb7281055dbf0ed4d041022a67c6c5cfd126f25, by setting port to -1.

This fixes qemuxml2argvtest test where the disk-drive-network-gluster
case was failing.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 8f17d0ea)
      3d021408
    • M
      security_selinux: Don't relabel /dev/net/tun · d72e79ed
      由 Michal Privoznik 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1147057

The code for relabelling the TAP FD is there due to a race. When
libvirt creates a /dev/tapN device it's labeled as
'system_u:object_r:device_t:s0' by default. Later, when
udev/systemd reacts to this device, it's relabelled to the
expected label 'system_u:object_r:tun_tap_device_t:s0'. Hence, we
have a code that relabels the device, to cut the race down. For
more info see ae368ebf.

But the problem is, the relabel function is called on all TUN/TAP
devices. Yes, on /dev/net/tun too. This is however a special kind
of device - other processes uses it too. We shouldn't touch it's
label then.

Ideally, there would an API in SELinux that would label just the
passed FD and not the underlying path. That way, we wouldn't need
to care as we would be not labeling /dev/net/tun but the FD
passed to the domain. Unfortunately, there's no such API so we
have to workaround until then.
Tested-by: NRichard W.M. Jones <rjones@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit ebc05263)
      d72e79ed
  3. 13 11月, 2014 1 次提交
    • L
      util: eliminate "use after free" in callers of virNetDevLinkDump · 7caed3d4
      由 Laine Stump 提交于 
      virNetDevLinkDump() gets a message from netlink into "resp", then
calls nlmsg_parse() to fill the table "tb" with pointers into resp. It
then returns tb to its caller, but not before freeing the buffer at
resp. That means that all the callers of virNetDevLinkDump() are
examining memory that has already been freed. This can be verified by
filling the buffer at resp with garbage prior to freeing it (or, I
suppose, just running libvirtd under valgrind) then performing some
operation that calls virNetDevLinkDump().

The upstream commit log incorrectly states that the code has been like
this ever since virNetDevLinkDump() was written. In reality, the
problem was introduced with commit e95de74d, first in libvirt-1.0.5,
which was attempting to eliminate a typecast that caused compiler
warnings. It has only been pure luck (or maybe a lack of heavy load,
and/or maybe an allocation algorithm in malloc() that delays re-use of
just-freed memory) that has kept this from causing errors, for example
when configuring a PCI passthrough or macvtap passthrough network
interface.

The solution taken in this patch is the simplest - just return resp to
the caller along with tb, then have the caller free it after they are
finished using the data (pointers) in tb. I alternately could have
made a cleaner interface by creating a new struct that put tb and resp
together along with a vir*Free() function for it, but this function is
only used in a couple places, and I'm not sure there will be
additional new uses of virNetDevLinkDump(), so the value of adding a
new type, extra APIs, etc. is dubious.

(cherry picked from commit f9f9699f)
      7caed3d4
  5. 07 11月, 2014 1 次提交
    • E
      CVE-2014-7823: dumpxml: security hole with migratable flag · 744ddb15
      由 Eric Blake 提交于 
      Commit 28f8dfdc (v1.0.0) introduced a security hole: in at least
the qemu implementation of virDomainGetXMLDesc, the use of the
flag VIR_DOMAIN_XML_MIGRATABLE (which is usable from a read-only
connection) triggers the implicit use of VIR_DOMAIN_XML_SECURE
prior to calling qemuDomainFormatXML.  However, the use of
VIR_DOMAIN_XML_SECURE is supposed to be restricted to read-write
clients only.  This patch treats the migratable flag as requiring
the same permissions, rather than analyzing what might break if
migratable xml no longer includes secret information.

Fortunately, the information leak is low-risk: all that is gated
by the VIR_DOMAIN_XML_SECURE flag is the VNC connection password;
but VNC passwords are already weak (FIPS forbids their use, and
on a non-FIPS machine, anyone stupid enough to trust a max-8-byte
password sent in plaintext over the network deserves what they
get).  SPICE offers better security than VNC, and all other
secrets are properly protected by use of virSecret associations
rather than direct output in domain XML.

* src/remote/remote_protocol.x (REMOTE_PROC_DOMAIN_GET_XML_DESC):
Tighten rules on use of migratable flag.
* src/libvirt-domain.c (virDomainGetXMLDesc): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit b1674ad5)

Conflicts:
	src/libvirt-domain.c - file split from older src/libvirt.c
Signed-off-by: NEric Blake <eblake@redhat.com>
      744ddb15
  7. 30 10月, 2014 3 次提交
    • L
      qemu: x86_64 is good enough for i686 · cd1b72fd
      由 Lubomir Rintel 提交于 
      virt-manager on Fedora sets up i686 hosts with "/usr/bin/qemu-kvm" emulator,
which in turn unconditionally execs qemu-system-x86_64 querying capabilities
then fails:

Error launching details: invalid argument: architecture from emulator 'x86_64' doesn't match given architecture 'i686'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 748, in _show_vm_helper
    details = self._get_details_dialog(uri, vm.get_connkey())
  File "/usr/share/virt-manager/virtManager/engine.py", line 726, in _get_details_dialog
    obj = vmmDetails(conn.get_vm(connkey))
  File "/usr/share/virt-manager/virtManager/details.py", line 399, in __init__
    self.init_details()
  File "/usr/share/virt-manager/virtManager/details.py", line 784, in init_details
    domcaps = self.vm.get_domain_capabilities()
  File "/usr/share/virt-manager/virtManager/domain.py", line 518, in get_domain_capabilities
    self.get_xmlobj().os.machine, self.get_xmlobj().type)
  File "/usr/lib/python2.7/site-packages/libvirt.py", line 3492, in getDomainCapabilities
    if ret is None: raise libvirtError ('virConnectGetDomainCapabilities() failed', conn=self)
libvirtError: invalid argument: architecture from emulator 'x86_64' doesn't match given architecture 'i686'

Journal:

Oct 16 21:08:26 goatlord.localdomain libvirtd[1530]: invalid argument: architecture from emulator 'x86_64' doesn't match given architecture 'i686'

(cherry picked from commit afe8f420)
      cd1b72fd
    • C
      qemu: Don't compare CPU against host for TCG · e9bf19a4
      由 Cole Robinson 提交于 
      Right now when building the qemu command line, we try to do various
unconditional validations of the guest CPU against the host CPU. However
this checks are overly applied. The only time we should use the checks
are:

- The user requests host-model/host-passthrough, or

- When KVM is requsted. CPU features requested in TCG mode are always
  emulated by qemu and are independent of the host CPU, so no host CPU
  checks should be performed.

Right now if trying to specify a CPU for arm on an x86 host, it attempts
to do non-sensical validation and falls over.

Switch all the test cases that were intending to test CPU validation to
use KVM, so they continue to test the intended code.

Amend some aarch64 XML tests with a CPU model, to ensure things work
correctly.

(cherry picked from commit cf7fce8f2fd1c930f357fd4ff93ac35f38eb30c6)
      e9bf19a4
    • C
      qemu_command: Split qemuBuildCpuArgStr · 74e27d1c
      由 Cole Robinson 提交于 
      Move the CPU mode/model handling to its own function. This is just
code movement and re-indentation.

(cherry picked from commit e1d872dc77c80d43036f928f83f560f2e9286148)
      74e27d1c
  9. 01 10月, 2014 2 次提交
  11. 30 9月, 2014 5 次提交
  13. 29 9月, 2014 3 次提交
  15. 27 9月, 2014 1 次提交
  17. 26 9月, 2014 10 次提交
  19. 25 9月, 2014 12 次提交