Compare commits

..

6 Commits
master ... f28

Author SHA1 Message Date
Cole Robinson d8f5f4e2e9 Fix virtlockd-admin.socket syntax (bz #1586239)
nwfilter: increase pcap buffer size to be compatible with TPACKET_V3 (bz #1547237)
2018-07-03 12:24:47 -04:00
Daniel P. Berrangé 7fa7c37eee Adapt to changed wireshark plugin install directory
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-06-18 19:03:25 +01:00
Daniel P. Berrangé 398721ffd4 Add new CPU features for speculative store bypass (CVE-2018-3639)
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-06-18 18:51:41 +01:00
Daniel P. Berrangé f6736a34a2 Fix systemd macro argument with line continuations (rhbz#1558648)
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-21 10:46:59 +00:00
Daniel P. Berrangé aa2d30880a Upload 4.1.0 sources
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-05 14:07:14 +00:00
Daniel P. Berrangé b6cdf32170 Rebase to version 4.1.0
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-05 14:07:14 +00:00
7 changed files with 906 additions and 342 deletions

View File

@ -0,0 +1,36 @@
From 519a6adb135959709fefbe30b7f40de436dd2f16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>
Date: Mon, 21 May 2018 23:05:07 +0100
Subject: [PATCH 1/2] cpu: define the 'ssbd' CPUID feature bit (CVE-2018-3639)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
New microcode introduces the "Speculative Store Bypass Disable"
CPUID feature bit. This needs to be exposed to guest OS to allow
them to protect against CVE-2018-3639.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
(cherry picked from commit 1dbca2eccad58d91a5fd33962854f1a653638182)
---
src/cpu/cpu_map.xml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml
index 00a43b172c..245aec3309 100644
--- a/src/cpu/cpu_map.xml
+++ b/src/cpu/cpu_map.xml
@@ -298,6 +298,9 @@
<feature name='spec-ctrl'>
<cpuid eax_in='0x07' ecx_in='0x00' edx='0x04000000'/>
</feature>
+ <feature name='ssbd'>
+ <cpuid eax_in='0x07' ecx_in='0x00' edx='0x80000000'/>
+ </feature>
<!-- Processor Extended State Enumeration sub leaf 1 -->
<feature name='xsaveopt'>
--
2.17.0

View File

@ -0,0 +1,69 @@
From ec92abee2851344e4e8c108a26b5cec594561ff4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>
Date: Mon, 5 Mar 2018 12:46:16 +0000
Subject: [PATCH] tests: force use of "NORMAL" TLS priority in test suite
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When generating certificates we rely on GNUTLS' built-in default setup
for the ciphers used in the certs. We then currently run with the distro
specific TLS priority setup which can be much stronger, to the extent
that the certificates we generate are considered untrustworthy. We don't
care about the quality of the ciphers we use in the test suite, so just
force the priority to "NORMAL" which should ensure our certs are
accepted by GNUTLS.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
tests/virnettlscontexttest.c | 4 ++--
tests/virnettlssessiontest.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/virnettlscontexttest.c b/tests/virnettlscontexttest.c
index 089c10e964..86647f3014 100644
--- a/tests/virnettlscontexttest.c
+++ b/tests/virnettlscontexttest.c
@@ -72,7 +72,7 @@ static int testTLSContextInit(const void *opaque)
data->crt,
KEYFILE,
NULL,
- NULL,
+ "NORMAL",
true,
true);
} else {
@@ -80,7 +80,7 @@ static int testTLSContextInit(const void *opaque)
NULL,
data->crt,
KEYFILE,
- NULL,
+ "NORMAL",
true,
true);
}
diff --git a/tests/virnettlssessiontest.c b/tests/virnettlssessiontest.c
index 6d639e5b16..7e85607181 100644
--- a/tests/virnettlssessiontest.c
+++ b/tests/virnettlssessiontest.c
@@ -113,7 +113,7 @@ static int testTLSSessionInit(const void *opaque)
data->servercrt,
KEYFILE,
data->wildcards,
- NULL,
+ "NORMAL",
false,
true);
@@ -121,7 +121,7 @@ static int testTLSSessionInit(const void *opaque)
NULL,
data->clientcrt,
KEYFILE,
- NULL,
+ "NORMAL",
false,
true);
--
2.14.3

View File

@ -0,0 +1,47 @@
From 40cf57b55f3af94163d7ef3d50aec6c5c79c139d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <berrange@redhat.com>
Date: Mon, 21 May 2018 23:05:08 +0100
Subject: [PATCH 2/2] cpu: define the 'virt-ssbd' CPUID feature bit
(CVE-2018-3639)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Some AMD processors only support a non-architectural means of
enabling Speculative Store Bypass Disable. To allow simplified
handling in virtual environments, hypervisors will expose an
architectural definition through CPUID bit 0x80000008_EBX[25].
This needs to be exposed to guest OS running on AMD x86 hosts to
allow them to protect against CVE-2018-3639.
Note that since this CPUID bit won't be present in the host CPUID
results on physical hosts, it will not be enabled automatically
in guests configured with "host-model" CPU unless using QEMU
version >= 2.9.0. Thus for older versions of QEMU, this feature
must be manually enabled using policy=force. Guests using the
"host-passthrough" CPU mode do not need special handling.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
(cherry picked from commit 9267342206ce17f6933d57a3128cdc504d5945c9)
---
src/cpu/cpu_map.xml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml
index 245aec3309..96daa0f9af 100644
--- a/src/cpu/cpu_map.xml
+++ b/src/cpu/cpu_map.xml
@@ -433,6 +433,9 @@
<feature name='ibpb'>
<cpuid eax_in='0x80000008' ebx='0x00001000'/>
</feature>
+ <feature name='virt-ssbd'>
+ <cpuid eax_in='0x80000008' ebx='0x02000000'/>
+ </feature>
<!-- models -->
<model name='486'>
--
2.17.0

View File

@ -0,0 +1,36 @@
From fb327ac2c3d721b4002852c520d9f39a35183e0d Mon Sep 17 00:00:00 2001
Message-Id: <fb327ac2c3d721b4002852c520d9f39a35183e0d.1530632931.git.crobinso@redhat.com>
From: Jim Fehlig <jfehlig@suse.com>
Date: Wed, 14 Mar 2018 16:42:39 -0600
Subject: [PATCH] lockd: fix typo in virtlockd-admin.socket
Commit ce7ae55ea1 introduced a typo in virtlockd-admin socket file
/usr/lib/systemd/system/virtlockd-admin.socket:7: Unknown lvalue
'Server' in section 'Socket'
Change 'Server' to 'Service'.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
---
src/locking/virtlockd-admin.socket.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/locking/virtlockd-admin.socket.in b/src/locking/virtlockd-admin.socket.in
index 1fa0a3dc33..2a7500f3d0 100644
--- a/src/locking/virtlockd-admin.socket.in
+++ b/src/locking/virtlockd-admin.socket.in
@@ -4,7 +4,7 @@ Before=libvirtd.service
[Socket]
ListenStream=@localstatedir@/run/libvirt/virtlockd-admin-sock
-Server=virtlockd.service
+Service=virtlockd.service
[Install]
WantedBy=sockets.target
--
2.17.1

View File

@ -0,0 +1,110 @@
From ce5aebeacd10a1c15cb3ee46a59c8b5ff235589e Mon Sep 17 00:00:00 2001
Message-Id: <ce5aebeacd10a1c15cb3ee46a59c8b5ff235589e.1530632895.git.crobinso@redhat.com>
From: Laine Stump <laine@laine.org>
Date: Wed, 25 Apr 2018 17:12:03 -0400
Subject: [PATCH] nwfilter: increase pcap buffer size to be compatible with
TPACKET_V3
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/1758037
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> (V1)
Reviewed-by: John Ferlan <jferlan@redhat.com>
Tested-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
---
src/nwfilter/nwfilter_dhcpsnoop.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/nwfilter/nwfilter_dhcpsnoop.c b/src/nwfilter/nwfilter_dhcpsnoop.c
index 6069e70460..50cfb944a2 100644
--- a/src/nwfilter/nwfilter_dhcpsnoop.c
+++ b/src/nwfilter/nwfilter_dhcpsnoop.c
@@ -256,10 +256,21 @@ struct _virNWFilterDHCPDecodeJob {
# define DHCP_BURST_INTERVAL_S 10 /* sec */
/*
- * libpcap 1.5 requires a 128kb buffer
- * 128 kb is bigger than (DHCP_PKT_BURST * PCAP_PBUFSIZE / 2)
+ * NB: Any libpcap built with HAVE_TPACKET3 will require
+ * PCAP_BUFFERSIZE to be at least 262144 (although
+ * pcap_set_buffer_size() with a lower value will succeed, and the
+ * error will only show up later when pcap_setfilter() is called).
+ *
+ * It is possible that in the future libpcap could increase the
+ * minimum size even further, but due to the fact that each guest
+ * using dhcp snooping keeps 2 pcap sockets open (and thus 2 buffers
+ * allocated) for the life of the guest, we want to minimize the
+ * length of the buffer, so instead of leaving it at the default size
+ * (2MB), we are setting it to the minimum viable size and including
+ * this clue in the source to help quickly resolve the problem when/if
+ * it reoccurs.
*/
-# define PCAP_BUFFERSIZE (128 * 1024)
+# define PCAP_BUFFERSIZE (256 * 1024)
# define MAX_QUEUED_JOBS (DHCP_PKT_BURST + 2 * DHCP_PKT_RATE)
@@ -1114,6 +1125,11 @@ virNWFilterSnoopDHCPOpen(const char *ifname, virMacAddr *mac,
goto cleanup_nohandle;
}
+ /* IMPORTANT: If there is any failure of *any* pcap_* function
+ * during setup of the socket, look to the comment where
+ * PCAP_BUFFERSIZE is defined. It may be too small, even if the
+ * generated error doesn't imply that.
+ */
if (pcap_set_snaplen(handle, PCAP_PBUFSIZE) < 0 ||
pcap_set_buffer_size(handle, PCAP_BUFFERSIZE) < 0 ||
pcap_activate(handle) < 0) {
--
2.17.1

File diff suppressed because it is too large Load Diff

View File

@ -1 +1 @@
SHA512 (libvirt-5.6.0.tar.xz) = 95fe931394fb31288faf73349bb298f08f63cf062f851b9935303145f8166f69128be9360757f0e1845256c14f4d7672843dba0dc6c086b1c3c8bfc035cc8986
SHA512 (libvirt-4.1.0.tar.xz) = 62d1a228adf3270cc6defe3cbf92dac8c4ce2c434c4d97219571ccef799a4f6304cfd1ba9938338356641285f53ac71145d7b398523021c5ea1dc8e3d49cf894