1. 09 5月, 2013 1 次提交
    • C
      build: work around broken kernel header · 71e88fc5
      Cole Robinson 提交于
      I got this scary warning during ./configure on rawhide:
      
      checking linux/if_bridge.h usability... no
      checking linux/if_bridge.h presence... yes
      configure: WARNING: linux/if_bridge.h: present but cannot be compiled
      configure: WARNING: linux/if_bridge.h:     check for missing prerequisite headers?
      configure: WARNING: linux/if_bridge.h: see the Autoconf documentation
      configure: WARNING: linux/if_bridge.h:     section "Present But Cannot Be Compiled"
      configure: WARNING: linux/if_bridge.h: proceeding with the compiler's result
      configure: WARNING:     ## ------------------------------------- ##
      configure: WARNING:     ## Report this to libvir-list@redhat.com ##
      configure: WARNING:     ## ------------------------------------- ##
      checking for linux/if_bridge.h... no
      
      * configure.ac (AC_CHECK_HEADERS): Provide struct in6_addr, since
      linux/if_bridge.h uses it without declaring it.
      (cherry picked from commit c308a9ae)
      (cherry picked from commit 7ae53f15)
      (cherry picked from commit 879f28a9)
      
      Conflicts:
      	configure.ac
      71e88fc5
  2. 08 5月, 2013 1 次提交
    • E
      build: avoid infinite autogen loop · f4d50d05
      Eric Blake 提交于
      Several people have reported that if the .gnulib submodule is dirty,
      then 'make' will go into an infinite loop attempting to rerun bootstrap,
      because that never cleans up the dirty submodule.  By default, we
      should halt and make the user investigate, but if the user doesn't
      know why or care that the submodule is dirty, I also added the ability
      to 'make CLEAN_SUBMODULE=1' to get things going again.
      
      Also, while testing this, I noticed that when a submodule update was
      needed, 'make' would first run autoreconf, then bootstrap (which
      reruns autoreconf); adding a strategic dependency allows for less work.
      
      * .gnulib: Update to latest, for maint.mk improvements.
      * cfg.mk (_autogen): Also hook maint.mk, to run before autoreconf.
      * autogen.sh (bootstrap): Refuse to run if gnulib is dirty, unless
      user requests discarding gnulib changes.
      (cherry picked from commit c5f16220)
      
      Conflicts:
      	.gnulib
      f4d50d05
  3. 06 5月, 2013 6 次提交
    • J
      netlink: Fix build with libnl-3 · 83b70f74
      Jiri Denemark 提交于
      Commit 64297313 added three direct
      references to nl_handle_* instead of using our aliases which hide
      differences between libnl-3 and libnl-1.
      (cherry picked from commit d9d39e62)
      83b70f74
    • C
      build: fix detection of netcf linked with libnl1 · 32aeec7b
      Christophe Fergeau 提交于
      Commit 9298bfbc introduced code to detect if netcf is linked with
      libnl1, and to prefer libnl1 over libnl3 when this is the case.
      This behaviour can be disabled by setting LIBNL_CFLAGS to any value,
      including the empty string.
      However, configure.ac sets LIBNL_CFLAGS to "" before attempting
      libnl detection, so the libnl1 detection code is always disabled.
      This caused issues on my f17 system where netcf is linked with libnl1
      but libvirt got built with libnl3.
      
      This commit removes the setting of the LIBNL_* variables to "" as
      this does not appear to be needed. After this change, libnl1 is
      used when building libvirt on my f17 system.
      (cherry picked from commit f6c29515)
      32aeec7b
    • E
      build: force libnl1 if netcf also used libnl1 · 85ed7307
      Eric Blake 提交于
      Recent spec file changes ensure that in distro situations, netcf
      and libvirt will link against the same libnl in order to avoid
      dumping core.  But for every-day development, if you use F17 and
      have the libnl3-devel headers available, libvirt was blindly
      linking against libnl3 even though F17 netcf still links against
      libnl1, making testing a self-built binary on F17 impossible.
      
      By making configure a little bit smarter, we can avoid this
      situation - we merely skip the probe of libnl-3 if we can prove
      that netcf is still using libnl-1.  I intentionally wrote the
      test so that we still favor libnl-3 if netcf is not installed or
      if we couldn't use ldd to determine things.
      
      Defaults being what they are, someone will invariably complain
      that our smarts were wrong.  Never fear - in that case, just run
      ./configure LIBNL_CFLAGS=..., where the fact that you set
      LIBNL_CFLAGS (even to the empty string) will go back to probing
      for libnl-3, regardless of netcf's choice.
      
      * configure.ac (LIBNL): Don't probe libnl3 if netcf doesn't use it.
      (cherry picked from commit 9298bfbc)
      85ed7307
    • S
      build: support libnl-3 · 01247d0c
      Serge Hallyn 提交于
      configure.ac: check for libnl-3 in addition to libnl-1
      
      src/Makefile.am: link against libnl when needed
      
      src/util/virnetlink.c:
      support libnl3 api.  To minimize impact on code flow, wrap the
      differences under the virNetlink* namespace.
      
      Unfortunately libnl3 moves netlink/msg.h to
      /usr/include/libnl3/netlink/msg.h, so the LIBNL_CFLAGS need to be added
      to a bunch of places where they weren't needed with libnl1.
      Signed-off-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit 60fb8a22)
      
      Conflicts:
      	src/Makefile.am - dbus changes not backported
      01247d0c
    • E
      Skip libxl driver on Xen 4.2 · 3390e973
      Eric Blake 提交于
      Specific to v0.9.11.  This is the opposite of commit dfa1e1dd,
      and done for the purposes of minimal code changes to allow
      compilation of libxl on Fedora 17 which still has experimental
      libxl 4.1, while still being able to compile the branch (minus
      libxl code) on Fedora 18 and later.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      3390e973
    • J
      Fix compilation of legacy xen driver with Xen 4.2 · fff0ce11
      Jim Fehlig 提交于
      In Xen 4.2, xs.h is deprecated in favor of xenstore.h.  xs.h now
      contains
      
      #warning xs.h is deprecated use xenstore.h instead
      #include <xenstore.h>
      
      which fails compilation when warnings are treated as errors.
      
      Introduce a configure-time check for xenstore.h and if found,
      use it instead of xs.h.
      (cherry picked from commit 416eca18)
      fff0ce11
  4. 27 3月, 2013 3 次提交
    • M
      qemu: Set migration FD blocking · 2f450cf2
      Michal Privoznik 提交于
      Since we switched from direct host migration scheme to the one,
      where we connect to the destination and then just pass a FD to a
      qemu, we have uncovered a qemu bug. Qemu expects migration FD to
      block. However, we are passing a nonblocking one which results in
      cryptic error messages like:
      
        qemu: warning: error while loading state section id 2
        load of migration failed
      
      The bug is already known to Qemu folks, but we should workaround
      already released Qemus. Patch has been originally proposed by Stefan
      Hajnoczi <stefanha@gmail.com>
      (cherry picked from commit ceb31795)
      2f450cf2
    • E
      build: further fixes for broken if_bridge.h · e474a208
      Eric Blake 提交于
      Commit c308a9ae was incomplete; it resolved the configure failure,
      but not a later build failure.
      
      * src/util/virnetdevbridge.c: Include pre-req header.
      * configure.ac (AC_CHECK_HEADERS): Prefer standard in.h over
      non-standard ip6.h.
      (cherry picked from commit 1bf661ca)
      
      Conflicts:
      	src/util/virnetdevbridge.c
      e474a208
    • C
      build: work around broken kernel header · 7ae53f15
      Cole Robinson 提交于
      I got this scary warning during ./configure on rawhide:
      
      checking linux/if_bridge.h usability... no
      checking linux/if_bridge.h presence... yes
      configure: WARNING: linux/if_bridge.h: present but cannot be compiled
      configure: WARNING: linux/if_bridge.h:     check for missing prerequisite headers?
      configure: WARNING: linux/if_bridge.h: see the Autoconf documentation
      configure: WARNING: linux/if_bridge.h:     section "Present But Cannot Be Compiled"
      configure: WARNING: linux/if_bridge.h: proceeding with the compiler's result
      configure: WARNING:     ## ------------------------------------- ##
      configure: WARNING:     ## Report this to libvir-list@redhat.com ##
      configure: WARNING:     ## ------------------------------------- ##
      checking for linux/if_bridge.h... no
      
      * configure.ac (AC_CHECK_HEADERS): Provide struct in6_addr, since
      linux/if_bridge.h uses it without declaring it.
      (cherry picked from commit c308a9ae)
      7ae53f15
  5. 29 1月, 2013 3 次提交
    • C
      Prep for release 0.9.11.9 · 83c58870
      Cole Robinson 提交于
      83c58870
    • D
      Fix race condition when destroying guests · 0231e37a
      Daniel P. Berrange 提交于
      When running virDomainDestroy, we need to make sure that no other
      background thread cleans up the domain while we're doing our work.
      This can happen if we release the domain object while in the
      middle of work, because the monitor might detect EOF in this window.
      For this reason we have a 'beingDestroyed' flag to stop the monitor
      from doing its normal cleanup. Unfortunately this flag was only
      being used to protect qemuDomainBeginJob, and not qemuProcessKill
      
      This left open a race condition where either libvirtd could crash,
      or alternatively report bogus error messages about the domain already
      having been destroyed to the caller
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      (cherry picked from commit 81621f3e)
      
      Conflicts:
      	src/qemu/qemu_driver.c
      0231e37a
    • P
      rpc: Fix crash on error paths of message dispatching · d0e15015
      Peter Krempa 提交于
      This patch resolves CVE-2013-0170:
      https://bugzilla.redhat.com/show_bug.cgi?id=893450
      
      When reading and dispatching of a message failed the message was freed
      but wasn't removed from the message queue.
      
      After that when the connection was about to be closed the pointer for
      the message was still present in the queue and it was passed to
      virNetMessageFree which tried to call the callback function from an
      uninitialized pointer.
      
      This patch removes the message from the queue before it's freed.
      
      * rpc/virnetserverclient.c: virNetServerClientDispatchRead:
          - avoid use after free of RPC messages
      (cherry picked from commit 46532e3e)
      d0e15015
  6. 09 1月, 2013 3 次提交
    • L
      util: fix botched check for new netlink request filters · 6b3edda2
      Laine Stump 提交于
      This is an adjustment to the fix for
      
        https://bugzilla.redhat.com/show_bug.cgi?id=889319
      
      to account for two bonehead mistakes I made.
      
      commit ac2797cf attempted to fix a
      problem with netlink in newer kernels requiring an extra attribute
      with a filter flag set in order to receive an IFLA_VFINFO_LIST from
      netlink. Unfortunately, the #ifdef that protected against compiling it
      in on systems without the new flag went a bit too far, assuring that
      the new code would *never* be compiled, and even if it had, the code
      was incorrect.
      
      The first problem was that, while some IFLA_* enum values are also
      their existence at compile time, IFLA_EXT_MASK *isn't* #defined, so
      checking to see if it's #defined is not a valid method of determining
      whether or not to add the attribute. Fortunately, the flag that is
      being set (RTEXT_FILTER_VF) *is* #defined, and it is never present if
      IFLA_EXT_MASK isn't, so it's sufficient to just check for that flag.
      
      And to top it off, due to the code not actually compiling when I
      thought it did, I didn't realize that I'd been given the wrong arglist
      to nla_put() - you can't just send a const value to nla_put, you have
      to send it a pointer to memory containing what you want to add to the
      message, along with the length of that memory.
      
      This time I've actually sent the patch over to the other machine
      that's experiencing the problem, applied it to the branch being used
      (0.10.2) and verified that it works properly, i.e. it does fix the
      problem it's supposed to fix. :-/
      (cherry picked from commit 7c366506)
      6b3edda2
    • L
      util: add missing error log messages when failing to get netlink VFINFO · a5e743c3
      Laine Stump 提交于
      This patch fixes the lack of error messages when libvirt fails to find
      VFINFO in a returned netlinke response message.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=827519#c10 is an example
      of the error message that was previously logged when the
      IFLA_VFINFO_LIST object was missing from the netlink response. The
      reason for this failure is detailed in
      
         https://bugzilla.redhat.com/show_bug.cgi?id=889319
      
      Even though that root problem has been fixed, the experience of
      finding the root cause shows us how important it is to properly log an
      error message in these cases. This patch *seems* to replace the entire
      function, but really most of the changes are due to moving code that
      was previously inside an if() statement out to the top level of the
      function (the original if() was reversed and made to log an error and
      return).
      (cherry picked from commit 846770e5)
      
      Conflicts:
        src/util/virnetdev.c: virNetDevError was replaced with virReportError
                              post-0.9.11. Also memcpy of mac addr was replaced
                              with a call to virMacAddrSetRaw.
      a5e743c3
    • L
      util: fix functions that retrieve SRIOV VF info · b20b391f
      Laine Stump 提交于
      This patch resolves:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=889319
      
      When assigning an SRIOV virtual function to a guest using "intelligent
      PCI passthrough" (<interface type='hostdev'>, which sets the MAC
      address and vlan tag of the VF before passing its info to qemu),
      libvirt first learns the current MAC address and vlan tag by sending
      an NLM_F_REQUEST message for the VF's PF (physical function) to the
      kernel via a NETLINK_ROUTE socket (see virNetDevLinkDump()); the
      response message's IFLA_VFINFO_LIST section is examined to extract the
      info for the particular VF being assigned.
      
      This worked fine with kernels up until kernel commit
      115c9b81928360d769a76c632bae62d15206a94a (first appearing in upstream
      kernel 3.3) which changed the ABI to not return IFLA_VFINFO_LIST in
      the response until a newly introduced IFLA_EXT_MASK field was included
      in the request, with the (newly introduced, of course) RTEXT_FILTER_VF
      flag set.
      
      The justification for this ABI change was that new fields had been
      added to the VFINFO, causing NLM_F_REQUEST messages to fail on systems
      with large numbers of VFs if the requesting application didn't have a
      large enough buffer for all the info. The idea is that most
      applications doing an NLM_F_REQUEST don't care about VFINFO anyway, so
      eliminating it from the response would lower the requirements on
      buffer size. Apparently, the people who pushed this patch made the
      mistaken assumption that iproute2 (the "ip" command) was the only
      package that used IFLA_VFINFO_LIST, so it wouldn't break anything else
      (and they made sure that iproute2 was fixed.
      
      The logic of this "fix" is debatable at best (one could claim that the
      proper fix would be for the applications in question to be fixed so
      that they properly sized the buffer, which is what libvirt does
      (purely by virtue of using libnl), but it is what it is and we have to
      deal with it.
      
      In order for <interface type='hostdev'> to work properly on systems
      with a kernel 3.3 or later, libvirt needs to add the afore-mentioned
      IFLA_EXT_MASK field with RTEXT_FILTER_VF set.
      
      Of course we also need to continue working on systems with older
      kernels, so that one bit of code is compiled conditionally. The one
      time this could cause problems is if the libvirt binary was built on a
      system without IFLA_EXT_MASK which was subsequently updated to a
      kernel that *did* have it. That could be solved by manually providing
      the values of IFLA_EXT_MASK and RTEXT_FILTER_VF and adding it to the
      message anyway, but I'm uncertain what that might actually do on a
      system that didn't support the message, so for the time being we'll
      just fail in that case (which will very likely never happen anyway).
      (cherry picked from commit ac2797cf)
      
      Conflicts:
      
       src/util/virnetdev.c: parameters of virNetlinkCommand were changed
                             post 0.9.11.
      b20b391f
  7. 14 12月, 2012 1 次提交
    • L
      network: prevent dnsmasq from listening on localhost · 9eb2b573
      Laine Stump 提交于
      This patch resolves the problem reported in:
      
         https://bugzilla.redhat.com/show_bug.cgi?id=886663
      
      The source of the problem was the fix for CVE 2011-3411:
      
         https://bugzilla.redhat.com/show_bug.cgi?id=833033
      
      which was originally committed upstream in commit
      753ff83a. That commit improperly
      removed the "--except-interface lo" from dnsmasq commandlines when
      --bind-dynamic was used (based on comments in the latter bug).
      
      It turns out that the problem reported in the CVE could be eliminated
      without removing "--except-interface lo", and removing it actually
      caused each instance of dnsmasq to listen on localhost on port 53,
      which created a new problem:
      
      If another instance of dnsmasq using "bind-interfaces" (instead of
      "bind-dynamic") had already been started (or if another instance
      started later used "bind-dynamic"), this wouldn't have any immediately
      visible ill effects, but if you tried to start another dnsmasq
      instance using "bind-interfaces" *after* starting any libvirt
      networks, the new dnsmasq would fail to start, because there was
      already another process listening on port 53.
      
      This patch changes the network driver to *always* add
      "except-interface=lo" to dnsmasq conf files, regardless of whether we use
      bind-dynamic or bind-interfaces. This way no libvirt dnsmasq instances
      are listening on localhost (and the CVE is still fixed).
      
      The actual code change is miniscule, but must be propogated through all
      of the test files as well.
      
      (This is *not* a cherry-pick of the upstream commit that fixes the bug
      (commit d66eb786), because subsequent
      to the CVE fix, another patch changed the network driver to put
      dnsmasq options in a conf file rather than directly on the dnsmasq
      commandline preserving the same options), so a cherry-pick is just one
      very large conflict.)
      9eb2b573
  8. 10 12月, 2012 7 次提交
    • C
      Prep for release 0.9.11.8 · 35472c92
      Cole Robinson 提交于
      35472c92
    • V
      qemu: pass -usb and usb hubs earlier, so USB disks with static address are handled properly · 5c881f35
      Vladislav Bogdanov 提交于
      (cherry picked from commit 81af5336)
      
      Conflicts:
      	src/qemu/qemu_command.c
      	tests/qemuxml2argvdata/qemuxml2argv-bios.args
      	tests/qemuxml2argvdata/qemuxml2argv-blkiotune-device.args
      	tests/qemuxml2argvdata/qemuxml2argv-blkiotune.args
      	tests/qemuxml2argvdata/qemuxml2argv-boot-menu-disable-drive-bootindex.args
      	tests/qemuxml2argvdata/qemuxml2argv-console-virtio-s390.args
      	tests/qemuxml2argvdata/qemuxml2argv-cpu-eoi-disabled.args
      	tests/qemuxml2argvdata/qemuxml2argv-cpu-eoi-enabled.args
      	tests/qemuxml2argvdata/qemuxml2argv-cputune.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-blockio.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-copy_on_read.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-auth.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-geometry.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-ide-drive-split.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-ide-wwn.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-ioeventfd.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-split.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.args
      	tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-s390.args
      	tests/qemuxml2argvdata/qemuxml2argv-eoi-disabled.args
      	tests/qemuxml2argvdata/qemuxml2argv-eoi-enabled.args
      	tests/qemuxml2argvdata/qemuxml2argv-event_idx.args
      	tests/qemuxml2argvdata/qemuxml2argv-graphics-spice.args
      	tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc.args
      	tests/qemuxml2argvdata/qemuxml2argv-hyperv.args
      	tests/qemuxml2argvdata/qemuxml2argv-kvmclock+eoi-disabled.args
      	tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.args
      	tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.args
      	tests/qemuxml2argvdata/qemuxml2argv-memtune.args
      	tests/qemuxml2argvdata/qemuxml2argv-metadata.args
      	tests/qemuxml2argvdata/qemuxml2argv-minimal-s390.args
      	tests/qemuxml2argvdata/qemuxml2argv-minimal.args
      	tests/qemuxml2argvdata/qemuxml2argv-misc-disable-s3.args
      	tests/qemuxml2argvdata/qemuxml2argv-misc-disable-suspends.args
      	tests/qemuxml2argvdata/qemuxml2argv-misc-enable-s4.args
      	tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.args
      	tests/qemuxml2argvdata/qemuxml2argv-net-virtio-s390.args
      	tests/qemuxml2argvdata/qemuxml2argv-numad-auto-memory-vcpu-cpuset.args
      	tests/qemuxml2argvdata/qemuxml2argv-numad-auto-memory-vcpu-no-cpuset-and-placement.args
      	tests/qemuxml2argvdata/qemuxml2argv-numad-auto-vcpu-static-numatune.args
      	tests/qemuxml2argvdata/qemuxml2argv-numad-static-memory-auto-vcpu.args
      	tests/qemuxml2argvdata/qemuxml2argv-numad.args
      	tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-disabled.args
      	tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-enabled.args
      	tests/qemuxml2argvdata/qemuxml2argv-seclabel-dynamic-baselabel.args
      	tests/qemuxml2argvdata/qemuxml2argv-seclabel-dynamic-override.args
      	tests/qemuxml2argvdata/qemuxml2argv-seclabel-dynamic.args
      	tests/qemuxml2argvdata/qemuxml2argv-seclabel-none.args
      	tests/qemuxml2argvdata/qemuxml2argv-seclabel-static-relabel.args
      	tests/qemuxml2argvdata/qemuxml2argv-seclabel-static.args
      	tests/qemuxml2argvdata/qemuxml2argv-smbios.args
      	tests/qemuxml2argvdata/qemuxml2argv-virtio-lun.args
      5c881f35
    • V
      qemu: Do not ignore address for USB disks · ff05b2c4
      Vladislav Bogdanov 提交于
      (cherry picked from commit 8f708761)
      ff05b2c4
    • S
      qemu: Fix name comparison in qemuMonitorJSONBlockIoThrottleInfo() · 6ca56496
      Stefan Hajnoczi 提交于
      The string comparison logic was inverted and matched the first drive
      that does *not* have the name we search for.
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      (cherry picked from commit 23d47b33)
      6ca56496
    • S
      qemu: Keep QEMU host drive prefix in BlkIoTune · 39a427e8
      Stefan Hajnoczi 提交于
      The QEMU -drive id= begins with libvirt's QEMU host drive prefix
      ("drive-"), which is stripped off in several places two convert between
      host ("-drive") and guest ("-device") device names.
      
      In the case of BlkIoTune it is unnecessary to strip the QEMU host drive
      prefix because we operate on "info block"/"query-block" output that uses
      host drive names.
      
      Stripping the prefix incorrectly caused string comparisons to fail since
      we were comparing the guest device name against the host device name.
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      (cherry picked from commit 04ee70bf)
      39a427e8
    • M
      dnsmasq: Fix parsing of the version number · ca1cebdb
      Michal Privoznik 提交于
      If debugging is enabled, the debug messages are sent to stderr.
      Moreover, if a command has catching of stderr set, the messages
      gets mixed with stdout output (assuming both outputs are stored
      in the same variable). The resulting string then doesn't
      necessarily have to start with desired prefix then. This bug
      exposes itself when parsing dnsmasq output:
      
      2012-12-06 11:18:11.445+0000: 18491: error :
      dnsmasqCapsSetFromBuffer:664 : internal error cannot parse
      /usr/sbin/dnsmasq version number in '2012-12-06
      11:11:02.232+0000: 18492: debug : virFileClose:72 : Closed fd 22'
      
      We can clearly see that the output of dnsmasq --version doesn't
      start with expected "Dnsmasq version " string but a libvirt debug
      output.
      (cherry picked from commit ff33f807)
      ca1cebdb
    • M
      dnsmasq: Fix parsing of the version number · 1917cc05
      Michal Privoznik 提交于
      If the debugging is enabled, the virCommand subsystem catches debug
      messages in the command output as well. In that case, we can't assume
      the string corresponding to command's stdout will start with specific
      prefix. But the prefix can be moved deeper in the string. This bug
      shows itself when parsing dnsmasq output:
      
      2012-12-06 11:18:11.445+0000: 18491: error :
      dnsmasqCapsSetFromBuffer:664 : internal error cannot parse
      /usr/sbin/dnsmasq version number in '2012-12-06 11:11:02.232+0000:
      18492: debug : virFileClose:72 : Closed fd 22'
      
      We can clearly see that the output of dnsmasq --version
      doesn't start with expected "Dnsmasq version " string but a libvirt
      debug output.
      (cherry picked from commit 51144313)
      1917cc05
  9. 04 12月, 2012 1 次提交
    • L
      conf: fix virDomainNetGetActualDirect*() and BridgeName() · 35ca0db3
      Laine Stump 提交于
      This resolves:
      
         https://bugzilla.redhat.com/show_bug.cgi?id=881480
      
      These three functions:
      
        virDomainNetGetActualBridgeName
        virDomainNetGetActualDirectDev
        virDomainNetGetActualDirectMode
      
      return attributes that are in a union whose contents are interpreted
      differently depending on the actual->type and so they should only
      return non-0 when actual->type is 'bridge' (in the first case) or
      'direct' (in the other two cases, but I had neglected to do that, so
      ...DirectDev() was returning bridge.brname (which happens to share the
      same spot in the union with direct.linkdev) if actual->type was
      'bridge', and ...BridgeName was returning direct.linkdev when
      actual->type was 'direct'.
      
      How does this involve Bug 881480 (which was about the inability to
      switch between two networks that both have "<forward mode='bridge'/>
      <bridge name='xxx'/>"? Whenever the return value of
      virDomainNetGetActualDirectDev() for the new and old network
      definitions doesn't match, qemuDomainChangeNet() requires a "complete
      reconnect" of the device, which qemu currently doesn't
      support. ...DirectDev() *should* have been returning NULL for old and
      new, but was instead returning the old and new bridge names, which
      differ.
      
      (The other two functions weren't causing any behavioral problems in
      virDomainChangeNet(), but their problem and fix was identical, so I
      included them in this same patch).
      35ca0db3
  10. 30 11月, 2012 3 次提交
    • L
      network: use dnsmasq --bind-dynamic when available · 2abde0ac
      Laine Stump 提交于
      This bug resolves CVE-2012-3411, which is described in the following
      bugzilla report:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=833033
      
      The following report is specifically for libvirt on Fedora:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=874702
      
      In short, a dnsmasq instance run with the intention of listening for
      DHCP/DNS requests only on a libvirt virtual network (which is
      constructed using a Linux host bridge) would also answer queries sent
      from outside the virtualization host.
      
      This patch takes advantage of a new dnsmasq option "--bind-dynamic",
      which will cause the listening socket to be setup such that it will
      only receive those requests that actually come in via the bridge
      interface. In order for this behavior to actually occur, not only must
      "--bind-interfaces" be replaced with "--bind-dynamic", but also all
      "--listen-address" options must be replaced with a single
      "--interface" option. Fully:
      
         --bind-interfaces --except-interface lo --listen-address x.x.x.x ...
      
      (with --listen-address possibly repeated) is replaced with:
      
         --bind-dynamic --interface virbrX
      
      Of course libvirt can't use this new option if the host's dnsmasq
      doesn't have it, but we still want libvirt to function (because the
      great majority of libvirt installations, which only have mode='nat'
      networks using RFC1918 private address ranges (e.g. 192.168.122.0/24),
      are immune to this vulnerability from anywhere beyond the local subnet
      of the host), so we use the new dnsmasqCaps API to check if dnsmasq
      supports the new option and, if not, we use the "old" option style
      instead. In order to assure that this permissiveness doesn't lead to a
      vulnerable system, we do check for non-private addresses in this case,
      and refuse to start the network if both a) we are using the old-style
      options, and b) the network has a publicly routable IP
      address. Hopefully this will provide the proper balance of not being
      disruptive to those not practically affected, and making sure that
      those who *are* affected get their dnsmasq upgraded.
      
      (--bind-dynamic was added to dnsmasq in upstream commit
      54dd393f3938fc0c19088fbd319b95e37d81a2b0, which was included in
      dnsmasq-2.63)
      
      (cherry picked from commit 753ff83a)
      Conflicts:
              src/network/bridge_driver.c
              * needed to change virReportError() to the older
                networkReportError()
      
      	tests/networkxml2argvdata/nat-network-dns-txt-record.argv
              * this test file has an example of an arg with embedded space,
                which gets sorrounded by '' in newer releases. Other
                items on the same line had been modified.
      
      	tests/networkxml2argvdata/routed-network.argv
              * in the newer releases, this test file had an --addn-hosts
                arg that didn't exist on this branch. Again, it was in the
                surrounding context of the changes that had been made on
                master.
      2abde0ac
    • L
      util: new virSocketAddrIsPrivate function · fe98b659
      Laine Stump 提交于
      This new function returns true if the given address is in the range of
      any "private" or "local" networks as defined in RFC1918 (IPv4) or
      RFC3484/RFC4193 (IPv6), otherwise they return false.
      
      These ranges are:
      
         192.168.0.0/16
         172.16.0.0/16
         10.0.0.0/24
         FC00::/7
         FEC0::/10
      
      (cherry picked from commit bf402e77)
      Conflicts:
          src/util/virsocketaddr.c
          src/util/virsocketaddr.h
           * both of these files had new functions that had been added
             at the same place virSocketAddrIsPrivate was being added,
             so the context on the branch didn't match.
      fe98b659
    • L
      util: capabilities detection for dnsmasq · db7159a1
      Laine Stump 提交于
      In order to optionally take advantage of new features in dnsmasq when
      the host's version of dnsmasq supports them, but still be able to run
      on hosts that don't support the new features, we need to be able to
      detect the version of dnsmasq running on the host, and possibly
      determine from the help output what options are in this dnsmasq.
      
      This patch implements a greatly simplified version of the capabilities
      code we already have for qemu. A dnsmasqCaps device can be created and
      populated either from running a program on disk, reading a file with
      the concatenated output of "dnsmasq --version; dnsmasq --help", or
      examining a buffer in memory that contains the concatenated output of
      those two commands. Simple functions to retrieve capabilities flags,
      the version number, and the path of the binary are also included.
      
      bridge_driver.c creates a single dnsmasqCaps object at driver startup,
      and disposes of it at driver shutdown. Any time it must be used, the
      dnsmasqCapsRefresh method is called - it checks the mtime of the
      binary, and re-runs the checks if the binary has changed.
      
      networkxml2argvtest.c creates 2 "artificial" dnsmasqCaps objects at
      startup - one "restricted" (doesn't support --bind-dynamic) and one
      "full" (does support --bind-dynamic). Some of the test cases use one
      and some the other, to make sure both code pathes are tested.
      
      (cherry picked from commit 719c2c76)
      
      Conflicts:
        src/network/bridge_driver.c
        * some new functions are missing in the backport, so they don't need
          to be modified.
        * Use dnsmasqCapsFree() instead of virObjectUnref()
        src/util/dnsmasq.c
        * eliminate use of virObject, since this version of libvirt
          doesn't yet have it
        * use networkReportError() instead of virReportError()
        * virBitmapAlloc() instead of virBitmapNew()
        src/util/dnsmasq.h
        * don't #include virobject.h
        * add prototype for dnsmasqCapsFree()
        src/libvirt_private.syms
        * export dnsmasqCapsFree
      db7159a1
  11. 06 11月, 2012 1 次提交
  12. 28 10月, 2012 8 次提交
  13. 17 10月, 2012 1 次提交
    • J
      qemu: Clear async job when p2p migration fails early · d325704a
      Jiri Denemark 提交于
      When p2p migration fails early because qemuMigrationIsAllowed or
      qemuMigrationIsSafe say migration should be cancelled, we fail to clear
      the migration-out async job. As a result of that, further APIs called
      for the same domain may fail with Timed out during operation: cannot
      acquire state change lock.
      
      Reported by Guido Winkelmann.
      d325704a
  14. 09 10月, 2012 1 次提交