Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 24 6月, 2019 3 次提交
  3. 28 4月, 2018 1 次提交
    • L
      nwfilter: increase pcap buffer size to be compatible with TPACKET_V3 · aa68d0db
      由 Laine Stump 提交于 
      When an nwfilter rule sets the parameter CTRL_IP_LEARNING to "dhcp",
this turns on the "dhcpsnoop" thread, which uses libpcap to monitor
traffic on the domain's tap device and extract the IP address from the
DHCP response.

If libpcap on the host is built with HAVE_TPACKET3 defined (to enable
support for TPACKET_V3), the dhcpsnoop code's initialization of the
libpcap socket would fail with the following error:

  virNWFilterSnoopDHCPOpen:1134 : internal error: pcap_setfilter: can't remove kernel filter: Bad file descriptor

It turns out that this was because TPACKET_V3 requires a larger buffer
size than libvirt was setting (we were setting it to 128k). Changing
the buffer size to 256k eliminates the error, and the dhcpsnoop thread
once again works properly.

A fuller explanation of why TPACKET_V3 requires such a large buffer,
for future git spelunkers:

libpcap calls setsockopt(... SOL_PACKET, PACKET_RX_RING...) to setup a
ring buffer for receiving packets; two of the attributes sent to this
API are called tp_frame_size, and tp_frame_nr. If libpcap was built
with HAVE_TPACKET3 defined, tp_trame_size is set to MAXIMUM_SNAPLEN
(defined in libpcap sources as 262144) and tp_frame_nr is set to:

 [the buffer size we set, i.e. PCAP_BUFFERSIZE i.e. 262144] / tp_frame_size.

So if PCAP_BUFFERSIZE < MAXIMUM_SNAPLEN, then tp_frame_nr (the number
of frames in the ring buffer) is 0, which is nonsensical. This same
value is later used as a multiplier to determine the size for a call
to malloc() (which would also fail).

(NB: if HAVE_TPACKET3 is *not* defined, then tp_frame_size is set to
the snaplen set by the user (in our case 576) plus a small amount to
account for ethernet headers, so 256k is far more than adequate)

Since the TPACKET_V3 code in libpcap actually reads multiple packets
into each frame, it's not a problem to have only a single frame
(especially when we are monitoring such infrequent traffic), so it's
okay to set this relatively small buffer size (in comparison to the
default, which is 2MB), which is important since every guest using
dhcp snooping in a nwfilter rule will hold 2 of these buffers for the
entire life of the guest.

Thanks to Christian Ehrhardt for discovering that buffer size was the
problem (this was not at all obvious from the error that was logged!)

Resolves: https://bugzilla.redhat.com/1547237
Fixes: https://bugs.launchpad.net/libvirt/+bug/1758037Signed-off-by: NLaine Stump <laine@laine.org>
Reviewed-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> (V1)
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Tested-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
(cherry picked from commit ce5aebea)
      aa68d0db
  5. 21 3月, 2018 1 次提交
    • L
      vbox: fix SEGV during dumpxml of a serial port · 5a81acc8
      由 Laine Stump 提交于 
      commit 77a12987 changed the "virDomainChrSourceDef source" inside
virDomainChrDef to "virDomainChrSourceDefPtr source", and started
allocating source inside virDomainChrDefNew(), but vboxDumpSerial()
was allocating a virDomainChrDef with a simple VIR_ALLOC() (i.e. never
calling virDomainChrDefNew()), so source was never initialized,
leading to a SEGV any time a serial port was present. The same problem
was created in vboxDumpParallel().

This patch changes vboxDumpSerial() and vboxDumpParallel() to use
virDomainChrDefNew() instead of VIR_ALLOC(), and changes both of those
functions to return an error if virDomainChrDef() (or any other
allocation) fails.

This resolves: https://bugzilla.redhat.com/1536649

(cherry picked from commit 9c27e464)
Signed-off-by: NLaine Stump <laine@laine.org>
      5a81acc8
  7. 14 2月, 2018 6 次提交
    • M
      qemuDomainAttachDeviceMknodHelper: Remove symlink before creating it · 979a7b3f
      由 Michal Privoznik 提交于 
      https://bugzilla.redhat.com/show_bug.cgi?id=1528502

So imagine you have /dev/blah symlink which points to /dev/sda.
You attach /dev/blah as disk to your domain. Libvirt correctly
creates the /dev/blah -> /dev/sda symlink in the qemu namespace.
However, then you detach the disk, change the symlink so that it
points to /dev/sdb and tries to attach the disk again. This time,
however, the attach fails (well, qemu attaches wrong disk)
because the code assumes that symlinks don't change. Well they
do.

This is inspired by test fix written by Eduardo Habkost.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
(cherry picked from commit db98e7f6)
      979a7b3f
    • D
      log: fix deadlock obtaining hostname (related CVE-2018-6764) · ee54b0bd
      由 Daniel P. Berrangé 提交于 
      The fix for CVE-2018-6764 introduced a potential deadlock scenario
that gets triggered by the NSS module when virGetHostname() calls
getaddrinfo to resolve the hostname:

 #0  0x00007f6e714b57e7 in futex_wait
 #1  futex_wait_simple
 #2  __pthread_once_slow
 #3  0x00007f6e71d16e7d in virOnce
 #4  0x00007f6e71d0997c in virLogInitialize
 #5  0x00007f6e71d0a09a in virLogVMessage
 #6  0x00007f6e71d09ffd in virLogMessage
 #7  0x00007f6e71d0db22 in virObjectNew
 #8  0x00007f6e71d0dbf1 in virObjectLockableNew
 #9  0x00007f6e71d0d3e5 in virMacMapNew
 #10 0x00007f6e71cdc50a in findLease
 #11 0x00007f6e71cdcc56 in _nss_libvirt_gethostbyname4_r
 #12 0x00007f6e724631fc in gaih_inet
 #13 0x00007f6e72464697 in __GI_getaddrinfo
 #14 0x00007f6e71d19e81 in virGetHostnameImpl
 #15 0x00007f6e71d1a057 in virGetHostnameQuiet
 #16 0x00007f6e71d09936 in virLogOnceInit
 #17 0x00007f6e71d09952 in virLogOnce
 #18 0x00007f6e714b5829 in __pthread_once_slow
 #19 0x00007f6e71d16e7d in virOnce
 #20 0x00007f6e71d0997c in virLogInitialize
 #21 0x00007f6e71d0a09a in virLogVMessage
 #22 0x00007f6e71d09ffd in virLogMessage
 #23 0x00007f6e71d0db22 in virObjectNew
 #24 0x00007f6e71d0dbf1 in virObjectLockableNew
 #25 0x00007f6e71d0d3e5 in virMacMapNew
 #26 0x00007f6e71cdc50a in findLease
 #27 0x00007f6e71cdc839 in _nss_libvirt_gethostbyname3_r
 #28 0x00007f6e71cdc724 in _nss_libvirt_gethostbyname2_r
 #29 0x00007f6e7248f72f in __gethostbyname2_r
 #30 0x00007f6e7248f494 in gethostbyname2
 #31 0x000056348c30c36d in hosts_keys
 #32 0x000056348c30b7d2 in main

Fortunately the extra stuff virGetHostname does is totally irrelevant to
the needs of the logging code, so we can just inline a call to the
native hostname() syscall directly.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit c2dc6698)
      ee54b0bd
    • A
      util: Fix syntax-check · abb70bb3
      由 Andrea Bolognani 提交于 
      Broken by 759b4d1b.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
(cherry picked from commit 6ce3acc1)
      abb70bb3
    • L
      virlog: determine the hostname on startup CVE-2018-6764 · 3aadeae9
      由 Lubomir Rintel 提交于 
      At later point it might not be possible or even safe to use getaddrinfo(). It
can in turn result in a load of NSS module.

Notably, on a LXC container startup we may find ourselves with the guest
filesystem already having replaced the host one. Loading a NSS module
from the guest tree would allow a malicous guest to escape the
confinement of its container environment because libvirt will not yet
have locked it down.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
(cherry picked from commit 759b4d1b)
      3aadeae9
    • P
      qemu: monitor: Decrease logging verbosity · 1f9a5094
      由 Peter Krempa 提交于 
      The PROBE macro used in qemuMonitorIOProcess and the VIR_DEBUG message
in qemuMonitorJSONIOProcess create a lot of logging churn when debug
logging is enabled during monitor communication.

The messages logged from the PROBE macro are rather useless since they
are reporting the partial state of receiving the reply from qemu. The
actual full reply is still logged in qemuMonitorJSONIOProcessLine once
the full message is received.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
(cherry picked from commit f10bb334)
      1f9a5094
    • P
      util: probe: Add quiet versions of the "PROBE" macro · 881d4b65
      由 Peter Krempa 提交于 
      PROBE macro adds a logging entry, when used in places seeing a lot of
traffic this can cause a significant slowdown.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
(cherry picked from commit f06e488d)
      881d4b65
  9. 04 12月, 2017 1 次提交
  11. 16 10月, 2017 1 次提交
    • D
      qemu: ensure TLS clients always verify the server certificate · dc6c4179
      由 Daniel P. Berrange 提交于 
      The default_tls_x509_verify (and related) parameters in qemu.conf
control whether the QEMU TLS servers request & verify certificates
from clients. This works as a simple access control system for
servers by requiring the CA to issue certs to permitted clients.
This use of client certificates is disabled by default, since it
requires extra work to issue client certificates.

Unfortunately the code was using this configuration parameter when
setting up both TLS clients and servers in QEMU. The result was that
TLS clients for character devices and disk devices had verification
turned off, meaning they would ignore errors while validating the
server certificate.

This allows for trivial MITM attacks between client and server,
as any certificate returned by the attacker will be accepted by
the client.

This is assigned CVE-2017-1000256  / LSN-2017-0002
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 441d3eb6)
      dc6c4179
  13. 04 9月, 2017 2 次提交
  15. 02 9月, 2017 3 次提交
  17. 01 9月, 2017 4 次提交
  19. 31 8月, 2017 4 次提交
  21. 30 8月, 2017 9 次提交
  23. 29 8月, 2017 5 次提交