2010-03-25 17:46:09 +00:00
|
|
|
/*
|
|
|
|
* nwfilter_gentech_driver.c: generic technology driver
|
|
|
|
*
|
2014-09-03 17:29:38 +00:00
|
|
|
* Copyright (C) 2011-2014 Red Hat, Inc.
|
2010-03-25 17:46:09 +00:00
|
|
|
* Copyright (C) 2010 IBM Corp.
|
|
|
|
* Copyright (C) 2010 Stefan Berger
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2012-09-20 22:30:55 +00:00
|
|
|
* License along with this library. If not, see
|
2012-07-21 10:06:23 +00:00
|
|
|
* <http://www.gnu.org/licenses/>.
|
2010-03-25 17:46:09 +00:00
|
|
|
*
|
|
|
|
* Author: Stefan Berger <stefanb@us.ibm.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
|
|
|
#include "internal.h"
|
|
|
|
|
2012-12-12 18:06:53 +00:00
|
|
|
#include "viralloc.h"
|
2012-12-12 17:59:27 +00:00
|
|
|
#include "virlog.h"
|
2010-03-25 17:46:09 +00:00
|
|
|
#include "domain_conf.h"
|
2012-12-13 18:21:53 +00:00
|
|
|
#include "virerror.h"
|
2010-03-25 17:46:09 +00:00
|
|
|
#include "nwfilter_gentech_driver.h"
|
|
|
|
#include "nwfilter_ebiptables_driver.h"
|
2012-06-01 23:32:06 +00:00
|
|
|
#include "nwfilter_dhcpsnoop.h"
|
2012-06-01 23:32:06 +00:00
|
|
|
#include "nwfilter_ipaddrmap.h"
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
#include "nwfilter_learnipaddr.h"
|
2011-11-02 16:10:56 +00:00
|
|
|
#include "virnetdev.h"
|
2011-11-03 13:41:40 +00:00
|
|
|
#include "datatypes.h"
|
2017-07-05 10:19:43 +00:00
|
|
|
#include "virsocketaddr.h"
|
2013-05-03 12:45:04 +00:00
|
|
|
#include "virstring.h"
|
2010-03-25 17:46:09 +00:00
|
|
|
|
|
|
|
#define VIR_FROM_THIS VIR_FROM_NWFILTER
|
|
|
|
|
2014-02-28 12:16:17 +00:00
|
|
|
VIR_LOG_INIT("nwfilter.nwfilter_gentech_driver");
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2012-06-01 23:32:06 +00:00
|
|
|
#define NWFILTER_STD_VAR_MAC NWFILTER_VARNAME_MAC
|
|
|
|
#define NWFILTER_STD_VAR_IP NWFILTER_VARNAME_IP
|
|
|
|
|
|
|
|
#define NWFILTER_DFLT_LEARN "any"
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
|
|
|
|
static int _virNWFilterTeardownFilter(const char *ifname);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
|
|
|
|
|
|
|
static virNWFilterTechDriverPtr filter_tech_drivers[] = {
|
|
|
|
&ebiptables_driver,
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2014-01-22 18:13:30 +00:00
|
|
|
/* Serializes instantiation of filters. This is necessary
|
2017-05-30 19:30:42 +00:00
|
|
|
* to avoid lock ordering deadlocks. eg virNWFilterInstantiateFilterUpdate
|
2014-01-22 18:13:30 +00:00
|
|
|
* will hold a lock on a virNWFilterObjPtr. This in turn invokes
|
2017-05-30 19:23:42 +00:00
|
|
|
* virNWFilterDoInstantiate which invokes virNWFilterDetermineMissingVarsRec
|
2017-05-30 21:27:04 +00:00
|
|
|
* which invokes virNWFilterObjListFindInstantiateFilter. This iterates over
|
|
|
|
* every single virNWFilterObjPtr in the list. So if 2 threads try to
|
|
|
|
* instantiate a filter in parallel, they'll both hold 1 lock at the top level
|
|
|
|
* in virNWFilterInstantiateFilterUpdate which will cause the other thread
|
|
|
|
* to deadlock in virNWFilterObjListFindInstantiateFilter.
|
2014-01-22 18:13:30 +00:00
|
|
|
*
|
|
|
|
* XXX better long term solution is to make virNWFilterObjList use a
|
|
|
|
* hash table as is done for virDomainObjList. You can then get
|
|
|
|
* lockless lookup of objects by name.
|
|
|
|
*/
|
|
|
|
static virMutex updateMutex;
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2014-01-22 18:13:30 +00:00
|
|
|
int virNWFilterTechDriversInit(bool privileged)
|
|
|
|
{
|
Convert 'int i' to 'size_t i' in src/nwfilter/ files
Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-08 14:09:33 +00:00
|
|
|
size_t i = 0;
|
2012-06-15 12:56:13 +00:00
|
|
|
VIR_DEBUG("Initializing NWFilter technology drivers");
|
2014-01-22 18:13:30 +00:00
|
|
|
if (virMutexInitRecursive(&updateMutex) < 0)
|
|
|
|
return -1;
|
|
|
|
|
2010-04-14 10:29:55 +00:00
|
|
|
while (filter_tech_drivers[i]) {
|
|
|
|
if (!(filter_tech_drivers[i]->flags & TECHDRV_FLAG_INITIALIZED))
|
2011-02-10 10:46:21 +00:00
|
|
|
filter_tech_drivers[i]->init(privileged);
|
2010-04-14 10:29:55 +00:00
|
|
|
i++;
|
|
|
|
}
|
2014-01-22 18:13:30 +00:00
|
|
|
return 0;
|
2010-04-14 10:29:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-01-22 18:13:30 +00:00
|
|
|
void virNWFilterTechDriversShutdown(void)
|
|
|
|
{
|
Convert 'int i' to 'size_t i' in src/nwfilter/ files
Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-08 14:09:33 +00:00
|
|
|
size_t i = 0;
|
2010-04-14 10:29:55 +00:00
|
|
|
while (filter_tech_drivers[i]) {
|
|
|
|
if ((filter_tech_drivers[i]->flags & TECHDRV_FLAG_INITIALIZED))
|
|
|
|
filter_tech_drivers[i]->shutdown();
|
|
|
|
i++;
|
|
|
|
}
|
2014-01-22 18:13:30 +00:00
|
|
|
virMutexDestroy(&updateMutex);
|
2010-04-14 10:29:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-03-25 17:46:09 +00:00
|
|
|
virNWFilterTechDriverPtr
|
2014-01-22 18:13:30 +00:00
|
|
|
virNWFilterTechDriverForName(const char *name)
|
|
|
|
{
|
Convert 'int i' to 'size_t i' in src/nwfilter/ files
Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-08 14:09:33 +00:00
|
|
|
size_t i = 0;
|
2010-03-25 17:46:09 +00:00
|
|
|
while (filter_tech_drivers[i]) {
|
2014-06-27 09:25:05 +00:00
|
|
|
if (STREQ(filter_tech_drivers[i]->name, name)) {
|
|
|
|
if ((filter_tech_drivers[i]->flags & TECHDRV_FLAG_INITIALIZED) == 0)
|
|
|
|
break;
|
|
|
|
return filter_tech_drivers[i];
|
|
|
|
}
|
|
|
|
i++;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
virNWFilterRuleInstFree(virNWFilterRuleInstPtr inst)
|
|
|
|
{
|
|
|
|
if (!inst)
|
|
|
|
return;
|
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
virNWFilterHashTableFree(inst->vars);
|
2010-03-25 17:46:09 +00:00
|
|
|
VIR_FREE(inst);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virNWFilterVarHashmapAddStdValues:
|
|
|
|
* @tables: pointer to hash tabel to add values to
|
|
|
|
* @macaddr: The string of the MAC address to add to the hash table,
|
|
|
|
* may be NULL
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
* @ipaddr: The string of the IP address to add to the hash table;
|
|
|
|
* may be NULL
|
2010-03-25 17:46:09 +00:00
|
|
|
*
|
2011-12-09 02:26:34 +00:00
|
|
|
* Returns 0 in case of success, -1 in case an error happened with
|
2010-03-25 17:46:09 +00:00
|
|
|
* error having been reported.
|
|
|
|
*
|
|
|
|
* Adds a couple of standard keys (MAC, IP) to the hash table.
|
|
|
|
*/
|
|
|
|
static int
|
2010-04-05 16:34:55 +00:00
|
|
|
virNWFilterVarHashmapAddStdValues(virNWFilterHashTablePtr table,
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
char *macaddr,
|
maint: avoid 'const fooPtr' in nwfilter files
'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can). But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).
Fix up offenders in nwfilter code.
This patch does nothing about the stupidity evident in having
__virNWFilterInstantiateFilter, _virNWFilterInstantiateFilter,
and virNWFilterInstantiateFilter, which differ only by leading
underscores, and which infringes on the namespace reserved to
the implementation - that would need to be a separate cleanup.
* src/nwfilter/nwfilter_dhcpsnoop.h (virNWFilterDHCPSnoopReq): Use
intended type.
* src/nwfilter/nwfilter_gentech_driver.h
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterInstantiataeFilterLate, virNWFilterTeardownFilter)
(virNWFilterCreateVarHashmap): Likewise.
* src/nwfilter/nwfilter_learnipaddr.h (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_conf.h (virNWFilterApplyBasicRules)
(virNWFilterApplyDHCPOnlyRules): Likewise.
(virNWFilterDefFormat): Make const-correct.
* src/conf/nwfilter_params.h (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple, virNWFilterVarValueGetCardinality)
(virNWFilterVarValueEqual, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarCombIterGetVarValue): Use intended type.
(virNWFilterVarValueGetNthValue): Make const-correct.
* src/nwfilter/nwfilter_dhcpsnoop.c (virNWFilterSnoopReqLeaseDel)
(virNWFilterSnoopIFKeyFMT, virNWFilterDHCPSnoopReq)
(virNWFilterSnoopPruneIter, virNWFilterSnoopRemAllReqIter)
(virNWFilterDHCPSnoopReq): Fix fallout.
* src/nwfilter/nwfilter_gentech_driver.c
(virNWFilterVarHashmapAddStdValues, virNWFilterCreateVarHashmap)
(virNWFilterInstantiate, __virNWFilterInstantiateFilter)
(_virNWFilterInstantiateFilter, virNWFilterInstantiateFilterLate)
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterRollbackUpdateFilter, virNWFilterTeardownFilter):
Likewise.
* src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_params.c (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple)
(virNWFilterVarValueGetCardinality, virNWFilterVarValueEqual)
(virNWFilterVarCombIterAddVariable)
(virNWFilterVarCombIterGetVarValue, virNWFilterVarValueCompare)
(virNWFilterFormatParamAttributes, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessGetIntIterId)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarValueGetNthValue): Likewise.
* src/nwfilter/nwfilter_ebiptables_driver.c (ebtablesApplyBasicRules)
(ebtablesApplyDHCPOnlyRules, ebiptablesRuleOrderSort)
(ebiptablesRuleOrderSortPtr): Likewise.
* src/conf/nwfilter_conf.c (virNWFilterDefEqual)
(virNWFilterDefFormat): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-10-07 16:55:22 +00:00
|
|
|
const virNWFilterVarValue *ipaddr)
|
2010-03-25 17:46:09 +00:00
|
|
|
{
|
2011-11-18 16:58:18 +00:00
|
|
|
virNWFilterVarValue *val;
|
|
|
|
|
2010-03-25 17:46:09 +00:00
|
|
|
if (macaddr) {
|
2011-11-18 16:58:18 +00:00
|
|
|
val = virNWFilterVarValueCreateSimple(macaddr);
|
|
|
|
if (!val)
|
2011-12-09 02:26:34 +00:00
|
|
|
return -1;
|
2011-11-18 16:58:18 +00:00
|
|
|
|
2010-03-25 17:46:09 +00:00
|
|
|
if (virHashAddEntry(table->hashTable,
|
|
|
|
NWFILTER_STD_VAR_MAC,
|
2011-11-18 16:58:18 +00:00
|
|
|
val) < 0) {
|
2012-07-18 11:45:15 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
"%s", _("Could not add variable 'MAC' to hashmap"));
|
2011-12-09 02:26:34 +00:00
|
|
|
return -1;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
if (ipaddr) {
|
2011-11-23 00:05:45 +00:00
|
|
|
val = virNWFilterVarValueCopy(ipaddr);
|
2011-11-18 16:58:18 +00:00
|
|
|
if (!val)
|
2011-12-09 02:26:34 +00:00
|
|
|
return -1;
|
2011-11-18 16:58:18 +00:00
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
if (virHashAddEntry(table->hashTable,
|
|
|
|
NWFILTER_STD_VAR_IP,
|
2011-11-18 16:58:18 +00:00
|
|
|
val) < 0) {
|
2012-07-18 11:45:15 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
"%s", _("Could not add variable 'IP' to hashmap"));
|
2011-12-09 02:26:34 +00:00
|
|
|
return -1;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-03-25 17:46:09 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virNWFilterCreateVarHashmap:
|
|
|
|
* @macaddr: pointer to string containing formatted MAC address of interface
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
* @ipaddr: pointer to string containing formatted IP address used by
|
|
|
|
* VM on this interface; may be NULL
|
2010-03-25 17:46:09 +00:00
|
|
|
*
|
|
|
|
* Create a hashmap used for evaluating the firewall rules. Initializes
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
* it with the standard variable 'MAC' and 'IP' if provided.
|
2010-03-25 17:46:09 +00:00
|
|
|
*
|
2013-10-11 14:07:23 +00:00
|
|
|
* Returns pointer to hashmap, NULL if an error occurred.
|
2010-03-25 17:46:09 +00:00
|
|
|
*/
|
|
|
|
virNWFilterHashTablePtr
|
2011-11-23 00:05:45 +00:00
|
|
|
virNWFilterCreateVarHashmap(char *macaddr,
|
maint: avoid 'const fooPtr' in nwfilter files
'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can). But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).
Fix up offenders in nwfilter code.
This patch does nothing about the stupidity evident in having
__virNWFilterInstantiateFilter, _virNWFilterInstantiateFilter,
and virNWFilterInstantiateFilter, which differ only by leading
underscores, and which infringes on the namespace reserved to
the implementation - that would need to be a separate cleanup.
* src/nwfilter/nwfilter_dhcpsnoop.h (virNWFilterDHCPSnoopReq): Use
intended type.
* src/nwfilter/nwfilter_gentech_driver.h
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterInstantiataeFilterLate, virNWFilterTeardownFilter)
(virNWFilterCreateVarHashmap): Likewise.
* src/nwfilter/nwfilter_learnipaddr.h (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_conf.h (virNWFilterApplyBasicRules)
(virNWFilterApplyDHCPOnlyRules): Likewise.
(virNWFilterDefFormat): Make const-correct.
* src/conf/nwfilter_params.h (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple, virNWFilterVarValueGetCardinality)
(virNWFilterVarValueEqual, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarCombIterGetVarValue): Use intended type.
(virNWFilterVarValueGetNthValue): Make const-correct.
* src/nwfilter/nwfilter_dhcpsnoop.c (virNWFilterSnoopReqLeaseDel)
(virNWFilterSnoopIFKeyFMT, virNWFilterDHCPSnoopReq)
(virNWFilterSnoopPruneIter, virNWFilterSnoopRemAllReqIter)
(virNWFilterDHCPSnoopReq): Fix fallout.
* src/nwfilter/nwfilter_gentech_driver.c
(virNWFilterVarHashmapAddStdValues, virNWFilterCreateVarHashmap)
(virNWFilterInstantiate, __virNWFilterInstantiateFilter)
(_virNWFilterInstantiateFilter, virNWFilterInstantiateFilterLate)
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterRollbackUpdateFilter, virNWFilterTeardownFilter):
Likewise.
* src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_params.c (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple)
(virNWFilterVarValueGetCardinality, virNWFilterVarValueEqual)
(virNWFilterVarCombIterAddVariable)
(virNWFilterVarCombIterGetVarValue, virNWFilterVarValueCompare)
(virNWFilterFormatParamAttributes, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessGetIntIterId)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarValueGetNthValue): Likewise.
* src/nwfilter/nwfilter_ebiptables_driver.c (ebtablesApplyBasicRules)
(ebtablesApplyDHCPOnlyRules, ebiptablesRuleOrderSort)
(ebiptablesRuleOrderSortPtr): Likewise.
* src/conf/nwfilter_conf.c (virNWFilterDefEqual)
(virNWFilterDefFormat): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-10-07 16:55:22 +00:00
|
|
|
const virNWFilterVarValue *ipaddr)
|
|
|
|
{
|
2010-03-25 17:46:09 +00:00
|
|
|
virNWFilterHashTablePtr table = virNWFilterHashTableCreate(0);
|
2013-07-04 10:12:44 +00:00
|
|
|
if (!table)
|
2010-03-25 17:46:09 +00:00
|
|
|
return NULL;
|
|
|
|
|
2011-12-09 02:26:34 +00:00
|
|
|
if (virNWFilterVarHashmapAddStdValues(table, macaddr, ipaddr) < 0) {
|
2010-03-25 17:46:09 +00:00
|
|
|
virNWFilterHashTableFree(table);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
return table;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-06-27 16:53:59 +00:00
|
|
|
/**
|
|
|
|
* Convert a virNWFilterHashTable into a string of comma-separated
|
|
|
|
* variable names.
|
|
|
|
*/
|
|
|
|
struct printString
|
|
|
|
{
|
2014-06-27 09:25:05 +00:00
|
|
|
virBuffer buf;
|
|
|
|
const char *separator;
|
|
|
|
bool reportMAC;
|
|
|
|
bool reportIP;
|
2011-06-27 16:53:59 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2016-02-12 09:03:50 +00:00
|
|
|
static int
|
2011-06-27 16:53:59 +00:00
|
|
|
printString(void *payload ATTRIBUTE_UNUSED, const void *name, void *data)
|
|
|
|
{
|
|
|
|
struct printString *ps = data;
|
|
|
|
|
2012-10-17 09:23:12 +00:00
|
|
|
if ((STREQ((char *)name, NWFILTER_STD_VAR_IP) && !ps->reportIP) ||
|
2011-06-27 16:53:59 +00:00
|
|
|
(STREQ((char *)name, NWFILTER_STD_VAR_MAC) && !ps->reportMAC))
|
2016-02-12 09:03:50 +00:00
|
|
|
return 0;
|
2011-06-27 16:53:59 +00:00
|
|
|
|
|
|
|
if (virBufferUse(&ps->buf) && ps->separator)
|
|
|
|
virBufferAdd(&ps->buf, ps->separator, -1);
|
|
|
|
|
|
|
|
virBufferAdd(&ps->buf, name, -1);
|
2016-02-12 09:03:50 +00:00
|
|
|
return 0;
|
2011-06-27 16:53:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* virNWFilterPrintVars
|
|
|
|
*
|
|
|
|
* @var: hash table containing variables
|
|
|
|
* @separator: separator to use between variable names, i.e., ", "
|
|
|
|
* @reportMAC: whether to report the 'MAC' variable
|
|
|
|
* @reportIP : whether to report the IP variable
|
|
|
|
*
|
|
|
|
* Returns a string of comma separated variable names
|
|
|
|
*/
|
|
|
|
static char *
|
|
|
|
virNWFilterPrintVars(virHashTablePtr vars,
|
|
|
|
const char *separator,
|
|
|
|
bool reportMAC,
|
|
|
|
bool reportIP)
|
|
|
|
{
|
2014-06-27 09:25:05 +00:00
|
|
|
struct printString ps = {
|
|
|
|
.buf = VIR_BUFFER_INITIALIZER,
|
|
|
|
.separator = separator,
|
|
|
|
.reportMAC = reportMAC,
|
|
|
|
.reportIP = reportIP,
|
|
|
|
};
|
|
|
|
|
|
|
|
virHashForEach(vars, printString, &ps);
|
|
|
|
|
2014-06-27 08:40:15 +00:00
|
|
|
if (virBufferCheckError(&ps.buf) < 0)
|
2014-06-27 09:25:05 +00:00
|
|
|
return NULL;
|
|
|
|
return virBufferContentAndReset(&ps.buf);
|
2011-06-27 16:53:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-03-25 17:46:09 +00:00
|
|
|
/**
|
|
|
|
* virNWFilterCreateVarsFrom:
|
|
|
|
* @vars1: pointer to hash table
|
|
|
|
* @vars2: pointer to hash table
|
|
|
|
*
|
|
|
|
* Returns pointer to new hashtable or NULL in case of error with
|
|
|
|
* error already reported.
|
|
|
|
*
|
|
|
|
* Creates a new hash table with contents of var1 and var2 added where
|
|
|
|
* contents of var2 will overwrite those of var1.
|
|
|
|
*/
|
|
|
|
static virNWFilterHashTablePtr
|
2010-04-05 16:34:55 +00:00
|
|
|
virNWFilterCreateVarsFrom(virNWFilterHashTablePtr vars1,
|
2010-03-25 17:46:09 +00:00
|
|
|
virNWFilterHashTablePtr vars2)
|
|
|
|
{
|
|
|
|
virNWFilterHashTablePtr res = virNWFilterHashTableCreate(0);
|
2013-07-04 10:12:44 +00:00
|
|
|
if (!res)
|
2010-03-25 17:46:09 +00:00
|
|
|
return NULL;
|
|
|
|
|
2011-12-09 02:26:34 +00:00
|
|
|
if (virNWFilterHashTablePutAll(vars1, res) < 0)
|
2010-03-25 17:46:09 +00:00
|
|
|
goto err_exit;
|
|
|
|
|
2011-12-09 02:26:34 +00:00
|
|
|
if (virNWFilterHashTablePutAll(vars2, res) < 0)
|
2010-03-25 17:46:09 +00:00
|
|
|
goto err_exit;
|
|
|
|
|
|
|
|
return res;
|
|
|
|
|
2014-03-25 06:56:49 +00:00
|
|
|
err_exit:
|
2010-03-25 17:46:09 +00:00
|
|
|
virNWFilterHashTableFree(res);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
typedef struct _virNWFilterInst virNWFilterInst;
|
|
|
|
typedef virNWFilterInst *virNWFilterInstPtr;
|
|
|
|
struct _virNWFilterInst {
|
|
|
|
virNWFilterObjPtr *filters;
|
|
|
|
size_t nfilters;
|
|
|
|
virNWFilterRuleInstPtr *rules;
|
|
|
|
size_t nrules;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
virNWFilterInstReset(virNWFilterInstPtr inst)
|
2010-03-25 17:46:09 +00:00
|
|
|
{
|
Convert 'int i' to 'size_t i' in src/nwfilter/ files
Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-08 14:09:33 +00:00
|
|
|
size_t i;
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
for (i = 0; i < inst->nfilters; i++)
|
|
|
|
virNWFilterObjUnlock(inst->filters[i]);
|
|
|
|
VIR_FREE(inst->filters);
|
|
|
|
inst->nfilters = 0;
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
for (i = 0; i < inst->nrules; i++)
|
|
|
|
virNWFilterRuleInstFree(inst->rules[i]);
|
|
|
|
VIR_FREE(inst->rules);
|
|
|
|
}
|
2010-03-25 17:46:09 +00:00
|
|
|
|
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
|
|
|
|
static int
|
|
|
|
virNWFilterDefToInst(virNWFilterDriverStatePtr driver,
|
|
|
|
virNWFilterDefPtr def,
|
|
|
|
virNWFilterHashTablePtr vars,
|
|
|
|
enum instCase useNewFilter,
|
|
|
|
bool *foundNewFilter,
|
|
|
|
virNWFilterInstPtr inst);
|
|
|
|
|
|
|
|
static int
|
|
|
|
virNWFilterRuleDefToRuleInst(virNWFilterDefPtr def,
|
|
|
|
virNWFilterRuleDefPtr rule,
|
|
|
|
virNWFilterHashTablePtr vars,
|
|
|
|
virNWFilterInstPtr inst)
|
|
|
|
{
|
|
|
|
virNWFilterRuleInstPtr ruleinst;
|
|
|
|
int ret = -1;
|
|
|
|
|
|
|
|
if (VIR_ALLOC(ruleinst) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
ruleinst->chainSuffix = def->chainsuffix;
|
|
|
|
ruleinst->chainPriority = def->chainPriority;
|
|
|
|
ruleinst->def = rule;
|
|
|
|
ruleinst->priority = rule->priority;
|
|
|
|
if (!(ruleinst->vars = virNWFilterHashTableCreate(0)))
|
|
|
|
goto cleanup;
|
|
|
|
if (virNWFilterHashTablePutAll(vars, ruleinst->vars) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
if (VIR_APPEND_ELEMENT(inst->rules,
|
|
|
|
inst->nrules,
|
|
|
|
ruleinst) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
inst = NULL;
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
|
|
|
virNWFilterRuleInstFree(ruleinst);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
virNWFilterIncludeDefToRuleInst(virNWFilterDriverStatePtr driver,
|
|
|
|
virNWFilterIncludeDefPtr inc,
|
|
|
|
virNWFilterHashTablePtr vars,
|
|
|
|
enum instCase useNewFilter,
|
|
|
|
bool *foundNewFilter,
|
|
|
|
virNWFilterInstPtr inst)
|
|
|
|
{
|
|
|
|
virNWFilterObjPtr obj;
|
|
|
|
virNWFilterHashTablePtr tmpvars = NULL;
|
|
|
|
virNWFilterDefPtr childdef;
|
2017-04-18 16:02:12 +00:00
|
|
|
virNWFilterDefPtr newChilddef;
|
2014-03-25 13:44:50 +00:00
|
|
|
int ret = -1;
|
|
|
|
|
|
|
|
VIR_DEBUG("Instantiating filter %s", inc->filterref);
|
2017-05-30 21:27:04 +00:00
|
|
|
if (!(obj = virNWFilterObjListFindInstantiateFilter(driver->nwfilters,
|
|
|
|
inc->filterref)))
|
2014-03-25 13:44:50 +00:00
|
|
|
goto cleanup;
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
/* create a temporary hashmap for depth-first tree traversal */
|
|
|
|
if (!(tmpvars = virNWFilterCreateVarsFrom(inc->params,
|
|
|
|
vars)))
|
|
|
|
goto cleanup;
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2017-04-18 16:02:12 +00:00
|
|
|
childdef = virNWFilterObjGetDef(obj);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
switch (useNewFilter) {
|
|
|
|
case INSTANTIATE_FOLLOW_NEWFILTER:
|
2017-04-18 16:02:12 +00:00
|
|
|
newChilddef = virNWFilterObjGetNewDef(obj);
|
|
|
|
if (newChilddef) {
|
|
|
|
childdef = newChilddef;
|
2014-03-25 13:44:50 +00:00
|
|
|
*foundNewFilter = true;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case INSTANTIATE_ALWAYS:
|
|
|
|
break;
|
|
|
|
}
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
if (VIR_APPEND_ELEMENT(inst->filters,
|
|
|
|
inst->nfilters,
|
|
|
|
obj) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
obj = NULL;
|
|
|
|
|
|
|
|
if (virNWFilterDefToInst(driver,
|
|
|
|
childdef,
|
|
|
|
tmpvars,
|
|
|
|
useNewFilter,
|
|
|
|
foundNewFilter,
|
|
|
|
inst) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
|
|
|
if (ret < 0)
|
|
|
|
virNWFilterInstReset(inst);
|
|
|
|
virNWFilterHashTableFree(tmpvars);
|
|
|
|
if (obj)
|
|
|
|
virNWFilterObjUnlock(obj);
|
|
|
|
return ret;
|
|
|
|
}
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
|
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
/**
|
|
|
|
* virNWFilterDefToInst:
|
|
|
|
* @driver: the driver state pointer
|
|
|
|
* @def: The filter to instantiate
|
|
|
|
* @vars: A map holding variable names and values used for instantiating
|
|
|
|
* the filter and its subfilters.
|
|
|
|
* @useNewFilter: instruct whether to use a newDef pointer rather than a
|
|
|
|
* def ptr which is useful during a filter update
|
|
|
|
* @foundNewFilter: pointer to int indivating whether a newDef pointer was
|
|
|
|
* ever used; variable expected to be initialized to 0 by caller
|
|
|
|
* @rulesout: array to be filled with rule instance
|
|
|
|
* @nrulesout: counter to be filled with number of rule instances
|
|
|
|
*
|
|
|
|
* Recursively expand a nested filter into a flat list of rule instances,
|
|
|
|
* in a depth-first traversal of the tree.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, -1 on error
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
virNWFilterDefToInst(virNWFilterDriverStatePtr driver,
|
|
|
|
virNWFilterDefPtr def,
|
|
|
|
virNWFilterHashTablePtr vars,
|
|
|
|
enum instCase useNewFilter,
|
|
|
|
bool *foundNewFilter,
|
|
|
|
virNWFilterInstPtr inst)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
int ret = -1;
|
|
|
|
|
|
|
|
for (i = 0; i < def->nentries; i++) {
|
|
|
|
if (def->filterEntries[i]->rule) {
|
|
|
|
if (virNWFilterRuleDefToRuleInst(def,
|
|
|
|
def->filterEntries[i]->rule,
|
|
|
|
vars,
|
|
|
|
inst) < 0)
|
|
|
|
goto cleanup;
|
|
|
|
} else if (def->filterEntries[i]->include) {
|
|
|
|
if (virNWFilterIncludeDefToRuleInst(driver,
|
|
|
|
def->filterEntries[i]->include,
|
|
|
|
vars,
|
|
|
|
useNewFilter, foundNewFilter,
|
|
|
|
inst) < 0)
|
|
|
|
goto cleanup;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
}
|
|
|
|
}
|
2014-03-25 13:44:50 +00:00
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
|
|
|
if (ret < 0)
|
|
|
|
virNWFilterInstReset(inst);
|
|
|
|
return ret;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int
|
2011-11-23 19:13:03 +00:00
|
|
|
virNWFilterDetermineMissingVarsRec(virNWFilterDefPtr filter,
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
virNWFilterHashTablePtr vars,
|
|
|
|
virNWFilterHashTablePtr missing_vars,
|
|
|
|
int useNewFilter,
|
|
|
|
virNWFilterDriverStatePtr driver)
|
|
|
|
{
|
2011-01-15 15:06:52 +00:00
|
|
|
virNWFilterObjPtr obj;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
int rc = 0;
|
Convert 'int i' to 'size_t i' in src/nwfilter/ files
Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-08 14:09:33 +00:00
|
|
|
size_t i, j;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
virNWFilterDefPtr next_filter;
|
2017-04-18 16:02:12 +00:00
|
|
|
virNWFilterDefPtr newNext_filter;
|
2011-11-18 16:58:18 +00:00
|
|
|
virNWFilterVarValuePtr val;
|
2017-05-30 21:27:04 +00:00
|
|
|
virNWFilterHashTablePtr tmpvars;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
|
|
|
|
for (i = 0; i < filter->nentries; i++) {
|
|
|
|
virNWFilterRuleDefPtr rule = filter->filterEntries[i]->rule;
|
|
|
|
virNWFilterIncludeDefPtr inc = filter->filterEntries[i]->include;
|
|
|
|
if (rule) {
|
2011-01-28 21:38:06 +00:00
|
|
|
/* check all variables of this rule */
|
2012-01-11 11:42:37 +00:00
|
|
|
for (j = 0; j < rule->nVarAccess; j++) {
|
2012-01-11 11:42:37 +00:00
|
|
|
if (!virNWFilterVarAccessIsAvailable(rule->varAccess[j],
|
|
|
|
vars)) {
|
2013-09-03 11:36:22 +00:00
|
|
|
char *varAccess;
|
2012-01-11 11:42:37 +00:00
|
|
|
virBuffer buf = VIR_BUFFER_INITIALIZER;
|
|
|
|
|
|
|
|
virNWFilterVarAccessPrint(rule->varAccess[j], &buf);
|
|
|
|
if (virBufferError(&buf)) {
|
|
|
|
virReportOOMError();
|
2017-09-29 13:18:53 +00:00
|
|
|
return -1;
|
2012-01-11 11:42:37 +00:00
|
|
|
}
|
|
|
|
|
2011-11-18 16:58:18 +00:00
|
|
|
val = virNWFilterVarValueCreateSimpleCopyValue("1");
|
|
|
|
if (!val) {
|
2012-01-11 11:42:37 +00:00
|
|
|
virBufferFreeAndReset(&buf);
|
2017-09-29 13:18:53 +00:00
|
|
|
return -1;
|
2011-11-18 16:58:18 +00:00
|
|
|
}
|
2012-01-11 11:42:37 +00:00
|
|
|
|
|
|
|
varAccess = virBufferContentAndReset(&buf);
|
2017-09-29 13:21:47 +00:00
|
|
|
rc = virNWFilterHashTablePut(missing_vars, varAccess, val);
|
2012-01-11 11:42:37 +00:00
|
|
|
VIR_FREE(varAccess);
|
2017-09-29 13:21:47 +00:00
|
|
|
if (rc < 0) {
|
|
|
|
virNWFilterVarValueFree(val);
|
|
|
|
return -1;
|
|
|
|
}
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
} else if (inc) {
|
2015-10-27 18:14:01 +00:00
|
|
|
VIR_DEBUG("Following filter %s", inc->filterref);
|
2017-05-30 21:27:04 +00:00
|
|
|
if (!(obj = virNWFilterObjListFindInstantiateFilter(driver->nwfilters,
|
2017-09-29 13:18:53 +00:00
|
|
|
inc->filterref)))
|
|
|
|
return -1;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
|
2017-05-30 21:27:04 +00:00
|
|
|
/* create a temporary hashmap for depth-first tree traversal */
|
|
|
|
if (!(tmpvars = virNWFilterCreateVarsFrom(inc->params, vars))) {
|
|
|
|
virNWFilterObjUnlock(obj);
|
2017-09-29 13:18:53 +00:00
|
|
|
return -1;
|
2017-05-30 21:27:04 +00:00
|
|
|
}
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
|
2017-05-30 21:27:04 +00:00
|
|
|
next_filter = virNWFilterObjGetDef(obj);
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
|
2017-05-30 21:27:04 +00:00
|
|
|
switch (useNewFilter) {
|
|
|
|
case INSTANTIATE_FOLLOW_NEWFILTER:
|
|
|
|
newNext_filter = virNWFilterObjGetNewDef(obj);
|
|
|
|
if (newNext_filter)
|
|
|
|
next_filter = newNext_filter;
|
|
|
|
break;
|
|
|
|
case INSTANTIATE_ALWAYS:
|
|
|
|
break;
|
|
|
|
}
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
|
2017-05-30 21:27:04 +00:00
|
|
|
rc = virNWFilterDetermineMissingVarsRec(next_filter,
|
|
|
|
tmpvars,
|
|
|
|
missing_vars,
|
|
|
|
useNewFilter,
|
|
|
|
driver);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2017-05-30 21:27:04 +00:00
|
|
|
virNWFilterHashTableFree(tmpvars);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2017-05-30 21:27:04 +00:00
|
|
|
virNWFilterObjUnlock(obj);
|
|
|
|
if (rc < 0)
|
2017-09-29 13:18:53 +00:00
|
|
|
return -1;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
}
|
2017-09-29 13:18:53 +00:00
|
|
|
return 0;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
2017-05-30 19:23:42 +00:00
|
|
|
* virNWFilterDoInstantiate:
|
2011-12-09 02:35:20 +00:00
|
|
|
* @vmuuid: The UUID of the VM
|
2010-03-25 17:46:09 +00:00
|
|
|
* @techdriver: The driver to use for instantiation
|
|
|
|
* @filter: The filter to instantiate
|
|
|
|
* @ifname: The name of the interface to apply the rules to
|
|
|
|
* @vars: A map holding variable names and values used for instantiating
|
|
|
|
* the filter and its subfilters.
|
2010-05-03 22:11:48 +00:00
|
|
|
* @forceWithPendingReq: Ignore the check whether a pending learn request
|
|
|
|
* is active; 'true' only when the rules are applied late
|
2010-03-25 17:46:09 +00:00
|
|
|
*
|
|
|
|
* Returns 0 on success, a value otherwise.
|
|
|
|
*
|
|
|
|
* Instantiate a filter by instantiating the filter itself along with
|
|
|
|
* all its subfilters in a depth-first traversal of the tree of referenced
|
|
|
|
* filters. The name of the interface to which the rules belong must be
|
|
|
|
* provided. Apply the values of variables as needed.
|
2010-11-20 01:41:25 +00:00
|
|
|
*
|
|
|
|
* Call this function while holding the NWFilter filter update lock
|
2010-03-25 17:46:09 +00:00
|
|
|
*/
|
|
|
|
static int
|
2017-05-30 19:23:42 +00:00
|
|
|
virNWFilterDoInstantiate(const unsigned char *vmuuid,
|
|
|
|
virNWFilterTechDriverPtr techdriver,
|
|
|
|
virNWFilterDefPtr filter,
|
|
|
|
const char *ifname,
|
|
|
|
int ifindex,
|
|
|
|
const char *linkdev,
|
|
|
|
virNWFilterHashTablePtr vars,
|
|
|
|
enum instCase useNewFilter,
|
|
|
|
bool *foundNewFilter,
|
|
|
|
bool teardownOld,
|
|
|
|
const virMacAddr *macaddr,
|
|
|
|
virNWFilterDriverStatePtr driver,
|
|
|
|
bool forceWithPendingReq)
|
2010-03-25 17:46:09 +00:00
|
|
|
{
|
|
|
|
int rc;
|
2014-03-25 13:44:50 +00:00
|
|
|
virNWFilterInst inst;
|
2013-05-24 10:14:02 +00:00
|
|
|
bool instantiate = true;
|
2011-06-27 16:53:59 +00:00
|
|
|
char *buf;
|
2012-06-01 23:32:06 +00:00
|
|
|
virNWFilterVarValuePtr lv;
|
|
|
|
const char *learning;
|
|
|
|
bool reportIP = false;
|
2010-03-25 17:46:09 +00:00
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
virNWFilterHashTablePtr missing_vars = virNWFilterHashTableCreate(0);
|
2014-03-25 13:44:50 +00:00
|
|
|
|
|
|
|
memset(&inst, 0, sizeof(inst));
|
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
if (!missing_vars) {
|
2011-12-09 02:26:34 +00:00
|
|
|
rc = -1;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
goto err_exit;
|
|
|
|
}
|
|
|
|
|
2011-11-23 19:13:03 +00:00
|
|
|
rc = virNWFilterDetermineMissingVarsRec(filter,
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
vars,
|
|
|
|
missing_vars,
|
|
|
|
useNewFilter,
|
|
|
|
driver);
|
2011-12-09 02:26:34 +00:00
|
|
|
if (rc < 0)
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
goto err_exit;
|
|
|
|
|
2012-06-01 23:32:06 +00:00
|
|
|
lv = virHashLookup(vars->hashTable, NWFILTER_VARNAME_CTRL_IP_LEARNING);
|
|
|
|
if (lv)
|
|
|
|
learning = virNWFilterVarValueGetNthValue(lv, 0);
|
|
|
|
else
|
|
|
|
learning = NULL;
|
|
|
|
|
|
|
|
if (learning == NULL)
|
|
|
|
learning = NWFILTER_DFLT_LEARN;
|
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
if (virHashSize(missing_vars->hashTable) == 1) {
|
|
|
|
if (virHashLookup(missing_vars->hashTable,
|
|
|
|
NWFILTER_STD_VAR_IP) != NULL) {
|
2012-06-01 23:32:06 +00:00
|
|
|
if (STRCASEEQ(learning, "none")) { /* no learning */
|
|
|
|
reportIP = true;
|
|
|
|
goto err_unresolvable_vars;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
}
|
2012-06-01 23:32:06 +00:00
|
|
|
if (STRCASEEQ(learning, "dhcp")) {
|
|
|
|
rc = virNWFilterDHCPSnoopReq(techdriver, ifname, linkdev,
|
2014-03-24 12:27:03 +00:00
|
|
|
vmuuid, macaddr,
|
2012-06-01 23:32:06 +00:00
|
|
|
filter->name, vars, driver);
|
|
|
|
goto err_exit;
|
|
|
|
} else if (STRCASEEQ(learning, "any")) {
|
|
|
|
if (virNWFilterLookupLearnReq(ifindex) == NULL) {
|
|
|
|
rc = virNWFilterLearnIPAddress(techdriver,
|
|
|
|
ifname,
|
|
|
|
ifindex,
|
|
|
|
linkdev,
|
2014-03-24 12:27:03 +00:00
|
|
|
macaddr,
|
2012-06-01 23:32:06 +00:00
|
|
|
filter->name,
|
|
|
|
vars, driver,
|
|
|
|
DETECT_DHCP|DETECT_STATIC);
|
|
|
|
}
|
|
|
|
goto err_exit;
|
|
|
|
} else {
|
|
|
|
rc = -1;
|
2012-07-18 11:45:15 +00:00
|
|
|
virReportError(VIR_ERR_PARSE_FAILED,
|
|
|
|
_("filter '%s' "
|
|
|
|
"learning value '%s' invalid."),
|
|
|
|
filter->name, learning);
|
2014-03-12 14:35:13 +00:00
|
|
|
goto err_exit;
|
2012-06-01 23:32:06 +00:00
|
|
|
}
|
2014-09-03 17:29:38 +00:00
|
|
|
} else {
|
2014-06-27 09:25:05 +00:00
|
|
|
goto err_unresolvable_vars;
|
2014-09-03 17:29:38 +00:00
|
|
|
}
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
} else if (virHashSize(missing_vars->hashTable) > 1) {
|
2011-06-27 16:53:59 +00:00
|
|
|
goto err_unresolvable_vars;
|
2010-05-03 22:11:48 +00:00
|
|
|
} else if (!forceWithPendingReq &&
|
|
|
|
virNWFilterLookupLearnReq(ifindex) != NULL) {
|
2010-04-30 12:12:26 +00:00
|
|
|
goto err_exit;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
}
|
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
rc = virNWFilterDefToInst(driver,
|
|
|
|
filter,
|
|
|
|
vars,
|
|
|
|
useNewFilter, foundNewFilter,
|
|
|
|
&inst);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2011-12-09 02:26:34 +00:00
|
|
|
if (rc < 0)
|
2010-03-25 17:46:09 +00:00
|
|
|
goto err_exit;
|
|
|
|
|
|
|
|
switch (useNewFilter) {
|
|
|
|
case INSTANTIATE_FOLLOW_NEWFILTER:
|
|
|
|
instantiate = *foundNewFilter;
|
2014-06-27 09:25:05 +00:00
|
|
|
break;
|
2010-03-25 17:46:09 +00:00
|
|
|
case INSTANTIATE_ALWAYS:
|
2013-05-24 10:14:02 +00:00
|
|
|
instantiate = true;
|
2014-06-27 09:25:05 +00:00
|
|
|
break;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (instantiate) {
|
2011-12-09 02:26:34 +00:00
|
|
|
if (virNWFilterLockIface(ifname) < 0)
|
2010-04-22 18:58:57 +00:00
|
|
|
goto err_exit;
|
|
|
|
|
2014-03-25 13:44:50 +00:00
|
|
|
rc = techdriver->applyNewRules(ifname, inst.rules, inst.nrules);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
|
|
|
if (teardownOld && rc == 0)
|
2011-11-23 19:13:03 +00:00
|
|
|
techdriver->tearOldRules(ifname);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2011-11-03 12:28:17 +00:00
|
|
|
if (rc == 0 && (virNetDevValidateConfig(ifname, NULL, ifindex) <= 0)) {
|
|
|
|
virResetLastError();
|
2010-04-22 18:58:57 +00:00
|
|
|
/* interface changed/disppeared */
|
|
|
|
techdriver->allTeardown(ifname);
|
2011-12-09 02:26:34 +00:00
|
|
|
rc = -1;
|
2010-04-22 18:58:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
virNWFilterUnlockIface(ifname);
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
2014-03-25 06:56:49 +00:00
|
|
|
err_exit:
|
2014-03-25 13:44:50 +00:00
|
|
|
virNWFilterInstReset(&inst);
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
virNWFilterHashTableFree(missing_vars);
|
|
|
|
|
2010-03-25 17:46:09 +00:00
|
|
|
return rc;
|
2011-06-27 16:53:59 +00:00
|
|
|
|
2014-03-25 06:56:49 +00:00
|
|
|
err_unresolvable_vars:
|
2011-06-27 16:53:59 +00:00
|
|
|
|
2012-06-01 23:32:06 +00:00
|
|
|
buf = virNWFilterPrintVars(missing_vars->hashTable, ", ", false, reportIP);
|
2011-06-27 16:53:59 +00:00
|
|
|
if (buf) {
|
2012-07-18 11:45:15 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("Cannot instantiate filter due to unresolvable "
|
|
|
|
"variables or unavailable list elements: %s"), buf);
|
2011-06-27 16:53:59 +00:00
|
|
|
VIR_FREE(buf);
|
|
|
|
}
|
|
|
|
|
2011-12-09 02:26:34 +00:00
|
|
|
rc = -1;
|
2011-06-27 16:53:59 +00:00
|
|
|
goto err_exit;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-11-20 01:41:25 +00:00
|
|
|
/*
|
|
|
|
* Call this function while holding the NWFilter filter update lock
|
|
|
|
*/
|
2010-03-25 17:46:09 +00:00
|
|
|
static int
|
2017-05-30 19:30:42 +00:00
|
|
|
virNWFilterInstantiateFilterUpdate(virNWFilterDriverStatePtr driver,
|
|
|
|
const unsigned char *vmuuid,
|
|
|
|
bool teardownOld,
|
|
|
|
const char *ifname,
|
|
|
|
int ifindex,
|
|
|
|
const char *linkdev,
|
|
|
|
const virMacAddr *macaddr,
|
|
|
|
const char *filtername,
|
|
|
|
virNWFilterHashTablePtr filterparams,
|
|
|
|
enum instCase useNewFilter,
|
|
|
|
bool forceWithPendingReq,
|
|
|
|
bool *foundNewFilter)
|
2010-03-25 17:46:09 +00:00
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
const char *drvname = EBIPTABLES_DRIVER_ID;
|
|
|
|
virNWFilterTechDriverPtr techdriver;
|
2011-01-15 15:06:52 +00:00
|
|
|
virNWFilterObjPtr obj;
|
2010-03-25 17:46:09 +00:00
|
|
|
virNWFilterHashTablePtr vars, vars1;
|
|
|
|
virNWFilterDefPtr filter;
|
2017-04-18 16:02:12 +00:00
|
|
|
virNWFilterDefPtr newFilter;
|
2010-03-25 17:46:09 +00:00
|
|
|
char vmmacaddr[VIR_MAC_STRING_BUFLEN] = {0};
|
|
|
|
char *str_macaddr = NULL;
|
2011-11-23 00:05:45 +00:00
|
|
|
virNWFilterVarValuePtr ipaddr;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
char *str_ipaddr = NULL;
|
2010-03-25 17:46:09 +00:00
|
|
|
|
|
|
|
techdriver = virNWFilterTechDriverForName(drvname);
|
|
|
|
|
|
|
|
if (!techdriver) {
|
2012-07-18 11:45:15 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("Could not get access to ACL tech "
|
|
|
|
"driver '%s'"),
|
|
|
|
drvname);
|
2011-12-09 02:26:34 +00:00
|
|
|
return -1;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
VIR_DEBUG("filter name: %s", filtername);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2017-05-30 21:27:04 +00:00
|
|
|
if (!(obj = virNWFilterObjListFindInstantiateFilter(driver->nwfilters,
|
|
|
|
filtername)))
|
2011-12-09 02:26:34 +00:00
|
|
|
return -1;
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2012-01-27 16:48:38 +00:00
|
|
|
virMacAddrFormat(macaddr, vmmacaddr);
|
2013-05-03 12:45:04 +00:00
|
|
|
if (VIR_STRDUP(str_macaddr, vmmacaddr) < 0) {
|
2011-12-09 02:26:34 +00:00
|
|
|
rc = -1;
|
2010-03-25 17:46:09 +00:00
|
|
|
goto err_exit;
|
|
|
|
}
|
|
|
|
|
2012-06-01 23:32:06 +00:00
|
|
|
ipaddr = virNWFilterIPAddrMapGetIPAddr(ifname);
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
|
2011-11-23 00:05:45 +00:00
|
|
|
vars1 = virNWFilterCreateVarHashmap(str_macaddr, ipaddr);
|
2010-03-25 17:46:09 +00:00
|
|
|
if (!vars1) {
|
2011-12-09 02:26:34 +00:00
|
|
|
rc = -1;
|
2010-03-25 17:46:09 +00:00
|
|
|
goto err_exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
str_macaddr = NULL;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
str_ipaddr = NULL;
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2010-04-05 16:34:55 +00:00
|
|
|
vars = virNWFilterCreateVarsFrom(vars1,
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
filterparams);
|
2010-03-25 17:46:09 +00:00
|
|
|
if (!vars) {
|
2011-12-09 02:26:34 +00:00
|
|
|
rc = -1;
|
2010-03-25 17:46:09 +00:00
|
|
|
goto err_exit_vars1;
|
|
|
|
}
|
|
|
|
|
2017-04-18 16:02:12 +00:00
|
|
|
filter = virNWFilterObjGetDef(obj);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
|
|
|
switch (useNewFilter) {
|
|
|
|
case INSTANTIATE_FOLLOW_NEWFILTER:
|
2017-04-18 16:02:12 +00:00
|
|
|
newFilter = virNWFilterObjGetNewDef(obj);
|
|
|
|
if (newFilter) {
|
|
|
|
filter = newFilter;
|
2010-05-03 22:14:58 +00:00
|
|
|
*foundNewFilter = true;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
2014-06-27 09:25:05 +00:00
|
|
|
break;
|
2010-03-25 17:46:09 +00:00
|
|
|
|
|
|
|
case INSTANTIATE_ALWAYS:
|
2014-06-27 09:25:05 +00:00
|
|
|
break;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
2017-05-30 19:23:42 +00:00
|
|
|
rc = virNWFilterDoInstantiate(vmuuid, techdriver, filter,
|
|
|
|
ifname, ifindex, linkdev,
|
|
|
|
vars, useNewFilter, foundNewFilter,
|
|
|
|
teardownOld, macaddr, driver,
|
|
|
|
forceWithPendingReq);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
|
|
|
virNWFilterHashTableFree(vars);
|
|
|
|
|
2014-03-25 06:56:49 +00:00
|
|
|
err_exit_vars1:
|
2010-03-25 17:46:09 +00:00
|
|
|
virNWFilterHashTableFree(vars1);
|
|
|
|
|
2014-03-25 06:56:49 +00:00
|
|
|
err_exit:
|
2011-01-15 15:06:52 +00:00
|
|
|
virNWFilterObjUnlock(obj);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
VIR_FREE(str_ipaddr);
|
2010-03-25 17:46:09 +00:00
|
|
|
VIR_FREE(str_macaddr);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
static int
|
2017-05-30 19:59:24 +00:00
|
|
|
virNWFilterInstantiateFilterInternal(virNWFilterDriverStatePtr driver,
|
|
|
|
const unsigned char *vmuuid,
|
|
|
|
const virDomainNetDef *net,
|
|
|
|
bool teardownOld,
|
|
|
|
enum instCase useNewFilter,
|
|
|
|
bool *foundNewFilter)
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
{
|
|
|
|
const char *linkdev = (net->type == VIR_DOMAIN_NET_TYPE_DIRECT)
|
|
|
|
? net->data.direct.linkdev
|
|
|
|
: NULL;
|
2010-04-22 18:58:57 +00:00
|
|
|
int ifindex;
|
2010-11-20 01:41:25 +00:00
|
|
|
int rc;
|
2010-04-22 18:58:57 +00:00
|
|
|
|
2014-01-22 18:13:30 +00:00
|
|
|
virMutexLock(&updateMutex);
|
|
|
|
|
2011-08-11 10:56:50 +00:00
|
|
|
/* after grabbing the filter update lock check for the interface; if
|
|
|
|
it's not there anymore its filters will be or are being removed
|
|
|
|
(while holding the lock) and we don't want to build new ones */
|
2011-11-03 09:21:35 +00:00
|
|
|
if (virNetDevExists(net->ifname) != 1 ||
|
|
|
|
virNetDevGetIndex(net->ifname, &ifindex) < 0) {
|
2011-08-11 10:56:50 +00:00
|
|
|
/* interfaces / VMs can disappear during filter instantiation;
|
|
|
|
don't mark it as an error */
|
2011-11-03 09:21:35 +00:00
|
|
|
virResetLastError();
|
2011-08-11 10:56:50 +00:00
|
|
|
rc = 0;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2017-05-30 19:30:42 +00:00
|
|
|
rc = virNWFilterInstantiateFilterUpdate(driver, vmuuid, teardownOld,
|
|
|
|
net->ifname, ifindex, linkdev,
|
|
|
|
&net->mac, net->filter,
|
|
|
|
net->filterparams, useNewFilter,
|
|
|
|
false, foundNewFilter);
|
2010-11-20 01:41:25 +00:00
|
|
|
|
2014-03-25 06:56:49 +00:00
|
|
|
cleanup:
|
2014-01-22 18:13:30 +00:00
|
|
|
virMutexUnlock(&updateMutex);
|
|
|
|
|
2010-11-20 01:41:25 +00:00
|
|
|
return rc;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int
|
2013-10-03 11:45:26 +00:00
|
|
|
virNWFilterInstantiateFilterLate(virNWFilterDriverStatePtr driver,
|
|
|
|
const unsigned char *vmuuid,
|
2011-12-09 02:35:20 +00:00
|
|
|
const char *ifname,
|
2010-04-22 18:58:57 +00:00
|
|
|
int ifindex,
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
const char *linkdev,
|
maint: avoid 'const fooPtr' in nwfilter files
'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can). But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).
Fix up offenders in nwfilter code.
This patch does nothing about the stupidity evident in having
__virNWFilterInstantiateFilter, _virNWFilterInstantiateFilter,
and virNWFilterInstantiateFilter, which differ only by leading
underscores, and which infringes on the namespace reserved to
the implementation - that would need to be a separate cleanup.
* src/nwfilter/nwfilter_dhcpsnoop.h (virNWFilterDHCPSnoopReq): Use
intended type.
* src/nwfilter/nwfilter_gentech_driver.h
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterInstantiataeFilterLate, virNWFilterTeardownFilter)
(virNWFilterCreateVarHashmap): Likewise.
* src/nwfilter/nwfilter_learnipaddr.h (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_conf.h (virNWFilterApplyBasicRules)
(virNWFilterApplyDHCPOnlyRules): Likewise.
(virNWFilterDefFormat): Make const-correct.
* src/conf/nwfilter_params.h (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple, virNWFilterVarValueGetCardinality)
(virNWFilterVarValueEqual, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarCombIterGetVarValue): Use intended type.
(virNWFilterVarValueGetNthValue): Make const-correct.
* src/nwfilter/nwfilter_dhcpsnoop.c (virNWFilterSnoopReqLeaseDel)
(virNWFilterSnoopIFKeyFMT, virNWFilterDHCPSnoopReq)
(virNWFilterSnoopPruneIter, virNWFilterSnoopRemAllReqIter)
(virNWFilterDHCPSnoopReq): Fix fallout.
* src/nwfilter/nwfilter_gentech_driver.c
(virNWFilterVarHashmapAddStdValues, virNWFilterCreateVarHashmap)
(virNWFilterInstantiate, __virNWFilterInstantiateFilter)
(_virNWFilterInstantiateFilter, virNWFilterInstantiateFilterLate)
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterRollbackUpdateFilter, virNWFilterTeardownFilter):
Likewise.
* src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_params.c (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple)
(virNWFilterVarValueGetCardinality, virNWFilterVarValueEqual)
(virNWFilterVarCombIterAddVariable)
(virNWFilterVarCombIterGetVarValue, virNWFilterVarValueCompare)
(virNWFilterFormatParamAttributes, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessGetIntIterId)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarValueGetNthValue): Likewise.
* src/nwfilter/nwfilter_ebiptables_driver.c (ebtablesApplyBasicRules)
(ebtablesApplyDHCPOnlyRules, ebiptablesRuleOrderSort)
(ebiptablesRuleOrderSortPtr): Likewise.
* src/conf/nwfilter_conf.c (virNWFilterDefEqual)
(virNWFilterDefFormat): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-10-07 16:55:22 +00:00
|
|
|
const virMacAddr *macaddr,
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
const char *filtername,
|
2013-10-03 11:45:26 +00:00
|
|
|
virNWFilterHashTablePtr filterparams)
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
{
|
|
|
|
int rc;
|
2010-05-03 22:14:58 +00:00
|
|
|
bool foundNewFilter = false;
|
|
|
|
|
2014-01-22 17:28:29 +00:00
|
|
|
virNWFilterReadLockFilterUpdates();
|
2014-01-22 18:13:30 +00:00
|
|
|
virMutexLock(&updateMutex);
|
2010-11-20 01:41:25 +00:00
|
|
|
|
2017-05-30 19:30:42 +00:00
|
|
|
rc = virNWFilterInstantiateFilterUpdate(driver, vmuuid, true,
|
|
|
|
ifname, ifindex, linkdev,
|
|
|
|
macaddr, filtername, filterparams,
|
|
|
|
INSTANTIATE_ALWAYS, true,
|
|
|
|
&foundNewFilter);
|
2011-12-09 02:26:34 +00:00
|
|
|
if (rc < 0) {
|
2011-01-28 21:38:06 +00:00
|
|
|
/* something went wrong... 'DOWN' the interface */
|
2011-11-03 12:28:17 +00:00
|
|
|
if ((virNetDevValidateConfig(ifname, NULL, ifindex) <= 0) ||
|
2011-11-02 16:10:56 +00:00
|
|
|
(virNetDevSetOnline(ifname, false) < 0)) {
|
2011-11-03 12:28:17 +00:00
|
|
|
virResetLastError();
|
2011-01-28 21:38:06 +00:00
|
|
|
/* assuming interface disappeared... */
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
_virNWFilterTeardownFilter(ifname);
|
|
|
|
}
|
|
|
|
}
|
2010-11-20 01:41:25 +00:00
|
|
|
|
|
|
|
virNWFilterUnlockFilterUpdates();
|
2014-01-22 18:13:30 +00:00
|
|
|
virMutexUnlock(&updateMutex);
|
2010-11-20 01:41:25 +00:00
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-03-25 17:46:09 +00:00
|
|
|
int
|
2013-10-03 11:45:26 +00:00
|
|
|
virNWFilterInstantiateFilter(virNWFilterDriverStatePtr driver,
|
2011-12-09 02:35:20 +00:00
|
|
|
const unsigned char *vmuuid,
|
maint: avoid 'const fooPtr' in nwfilter files
'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can). But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).
Fix up offenders in nwfilter code.
This patch does nothing about the stupidity evident in having
__virNWFilterInstantiateFilter, _virNWFilterInstantiateFilter,
and virNWFilterInstantiateFilter, which differ only by leading
underscores, and which infringes on the namespace reserved to
the implementation - that would need to be a separate cleanup.
* src/nwfilter/nwfilter_dhcpsnoop.h (virNWFilterDHCPSnoopReq): Use
intended type.
* src/nwfilter/nwfilter_gentech_driver.h
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterInstantiataeFilterLate, virNWFilterTeardownFilter)
(virNWFilterCreateVarHashmap): Likewise.
* src/nwfilter/nwfilter_learnipaddr.h (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_conf.h (virNWFilterApplyBasicRules)
(virNWFilterApplyDHCPOnlyRules): Likewise.
(virNWFilterDefFormat): Make const-correct.
* src/conf/nwfilter_params.h (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple, virNWFilterVarValueGetCardinality)
(virNWFilterVarValueEqual, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarCombIterGetVarValue): Use intended type.
(virNWFilterVarValueGetNthValue): Make const-correct.
* src/nwfilter/nwfilter_dhcpsnoop.c (virNWFilterSnoopReqLeaseDel)
(virNWFilterSnoopIFKeyFMT, virNWFilterDHCPSnoopReq)
(virNWFilterSnoopPruneIter, virNWFilterSnoopRemAllReqIter)
(virNWFilterDHCPSnoopReq): Fix fallout.
* src/nwfilter/nwfilter_gentech_driver.c
(virNWFilterVarHashmapAddStdValues, virNWFilterCreateVarHashmap)
(virNWFilterInstantiate, __virNWFilterInstantiateFilter)
(_virNWFilterInstantiateFilter, virNWFilterInstantiateFilterLate)
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterRollbackUpdateFilter, virNWFilterTeardownFilter):
Likewise.
* src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_params.c (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple)
(virNWFilterVarValueGetCardinality, virNWFilterVarValueEqual)
(virNWFilterVarCombIterAddVariable)
(virNWFilterVarCombIterGetVarValue, virNWFilterVarValueCompare)
(virNWFilterFormatParamAttributes, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessGetIntIterId)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarValueGetNthValue): Likewise.
* src/nwfilter/nwfilter_ebiptables_driver.c (ebtablesApplyBasicRules)
(ebtablesApplyDHCPOnlyRules, ebiptablesRuleOrderSort)
(ebiptablesRuleOrderSortPtr): Likewise.
* src/conf/nwfilter_conf.c (virNWFilterDefEqual)
(virNWFilterDefFormat): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-10-07 16:55:22 +00:00
|
|
|
const virDomainNetDef *net)
|
2010-03-25 17:46:09 +00:00
|
|
|
{
|
2010-05-03 22:14:58 +00:00
|
|
|
bool foundNewFilter = false;
|
|
|
|
|
2017-05-30 19:59:24 +00:00
|
|
|
return virNWFilterInstantiateFilterInternal(driver, vmuuid, net,
|
|
|
|
1,
|
|
|
|
INSTANTIATE_ALWAYS,
|
|
|
|
&foundNewFilter);
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int
|
2013-10-03 11:45:26 +00:00
|
|
|
virNWFilterUpdateInstantiateFilter(virNWFilterDriverStatePtr driver,
|
2011-12-09 02:35:20 +00:00
|
|
|
const unsigned char *vmuuid,
|
maint: avoid 'const fooPtr' in nwfilter files
'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can). But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).
Fix up offenders in nwfilter code.
This patch does nothing about the stupidity evident in having
__virNWFilterInstantiateFilter, _virNWFilterInstantiateFilter,
and virNWFilterInstantiateFilter, which differ only by leading
underscores, and which infringes on the namespace reserved to
the implementation - that would need to be a separate cleanup.
* src/nwfilter/nwfilter_dhcpsnoop.h (virNWFilterDHCPSnoopReq): Use
intended type.
* src/nwfilter/nwfilter_gentech_driver.h
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterInstantiataeFilterLate, virNWFilterTeardownFilter)
(virNWFilterCreateVarHashmap): Likewise.
* src/nwfilter/nwfilter_learnipaddr.h (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_conf.h (virNWFilterApplyBasicRules)
(virNWFilterApplyDHCPOnlyRules): Likewise.
(virNWFilterDefFormat): Make const-correct.
* src/conf/nwfilter_params.h (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple, virNWFilterVarValueGetCardinality)
(virNWFilterVarValueEqual, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarCombIterGetVarValue): Use intended type.
(virNWFilterVarValueGetNthValue): Make const-correct.
* src/nwfilter/nwfilter_dhcpsnoop.c (virNWFilterSnoopReqLeaseDel)
(virNWFilterSnoopIFKeyFMT, virNWFilterDHCPSnoopReq)
(virNWFilterSnoopPruneIter, virNWFilterSnoopRemAllReqIter)
(virNWFilterDHCPSnoopReq): Fix fallout.
* src/nwfilter/nwfilter_gentech_driver.c
(virNWFilterVarHashmapAddStdValues, virNWFilterCreateVarHashmap)
(virNWFilterInstantiate, __virNWFilterInstantiateFilter)
(_virNWFilterInstantiateFilter, virNWFilterInstantiateFilterLate)
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterRollbackUpdateFilter, virNWFilterTeardownFilter):
Likewise.
* src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_params.c (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple)
(virNWFilterVarValueGetCardinality, virNWFilterVarValueEqual)
(virNWFilterVarCombIterAddVariable)
(virNWFilterVarCombIterGetVarValue, virNWFilterVarValueCompare)
(virNWFilterFormatParamAttributes, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessGetIntIterId)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarValueGetNthValue): Likewise.
* src/nwfilter/nwfilter_ebiptables_driver.c (ebtablesApplyBasicRules)
(ebtablesApplyDHCPOnlyRules, ebiptablesRuleOrderSort)
(ebiptablesRuleOrderSortPtr): Likewise.
* src/conf/nwfilter_conf.c (virNWFilterDefEqual)
(virNWFilterDefFormat): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-10-07 16:55:22 +00:00
|
|
|
const virDomainNetDef *net,
|
2010-05-03 22:14:58 +00:00
|
|
|
bool *skipIface)
|
2010-03-25 17:46:09 +00:00
|
|
|
{
|
2010-05-03 22:14:58 +00:00
|
|
|
bool foundNewFilter = false;
|
|
|
|
|
2017-05-30 19:59:24 +00:00
|
|
|
int rc = virNWFilterInstantiateFilterInternal(driver, vmuuid, net,
|
|
|
|
0,
|
|
|
|
INSTANTIATE_FOLLOW_NEWFILTER,
|
|
|
|
&foundNewFilter);
|
2010-05-03 22:14:58 +00:00
|
|
|
|
|
|
|
*skipIface = !foundNewFilter;
|
|
|
|
return rc;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
2011-12-09 02:26:34 +00:00
|
|
|
static int
|
maint: avoid 'const fooPtr' in nwfilter files
'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can). But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).
Fix up offenders in nwfilter code.
This patch does nothing about the stupidity evident in having
__virNWFilterInstantiateFilter, _virNWFilterInstantiateFilter,
and virNWFilterInstantiateFilter, which differ only by leading
underscores, and which infringes on the namespace reserved to
the implementation - that would need to be a separate cleanup.
* src/nwfilter/nwfilter_dhcpsnoop.h (virNWFilterDHCPSnoopReq): Use
intended type.
* src/nwfilter/nwfilter_gentech_driver.h
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterInstantiataeFilterLate, virNWFilterTeardownFilter)
(virNWFilterCreateVarHashmap): Likewise.
* src/nwfilter/nwfilter_learnipaddr.h (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_conf.h (virNWFilterApplyBasicRules)
(virNWFilterApplyDHCPOnlyRules): Likewise.
(virNWFilterDefFormat): Make const-correct.
* src/conf/nwfilter_params.h (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple, virNWFilterVarValueGetCardinality)
(virNWFilterVarValueEqual, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarCombIterGetVarValue): Use intended type.
(virNWFilterVarValueGetNthValue): Make const-correct.
* src/nwfilter/nwfilter_dhcpsnoop.c (virNWFilterSnoopReqLeaseDel)
(virNWFilterSnoopIFKeyFMT, virNWFilterDHCPSnoopReq)
(virNWFilterSnoopPruneIter, virNWFilterSnoopRemAllReqIter)
(virNWFilterDHCPSnoopReq): Fix fallout.
* src/nwfilter/nwfilter_gentech_driver.c
(virNWFilterVarHashmapAddStdValues, virNWFilterCreateVarHashmap)
(virNWFilterInstantiate, __virNWFilterInstantiateFilter)
(_virNWFilterInstantiateFilter, virNWFilterInstantiateFilterLate)
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterRollbackUpdateFilter, virNWFilterTeardownFilter):
Likewise.
* src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_params.c (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple)
(virNWFilterVarValueGetCardinality, virNWFilterVarValueEqual)
(virNWFilterVarCombIterAddVariable)
(virNWFilterVarCombIterGetVarValue, virNWFilterVarValueCompare)
(virNWFilterFormatParamAttributes, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessGetIntIterId)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarValueGetNthValue): Likewise.
* src/nwfilter/nwfilter_ebiptables_driver.c (ebtablesApplyBasicRules)
(ebtablesApplyDHCPOnlyRules, ebiptablesRuleOrderSort)
(ebiptablesRuleOrderSortPtr): Likewise.
* src/conf/nwfilter_conf.c (virNWFilterDefEqual)
(virNWFilterDefFormat): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-10-07 16:55:22 +00:00
|
|
|
virNWFilterRollbackUpdateFilter(const virDomainNetDef *net)
|
2010-03-25 17:46:09 +00:00
|
|
|
{
|
|
|
|
const char *drvname = EBIPTABLES_DRIVER_ID;
|
2010-04-30 12:12:26 +00:00
|
|
|
int ifindex;
|
2010-03-25 17:46:09 +00:00
|
|
|
virNWFilterTechDriverPtr techdriver;
|
2010-04-30 12:12:26 +00:00
|
|
|
|
2010-03-25 17:46:09 +00:00
|
|
|
techdriver = virNWFilterTechDriverForName(drvname);
|
|
|
|
if (!techdriver) {
|
2012-07-18 11:45:15 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("Could not get access to ACL tech "
|
|
|
|
"driver '%s'"),
|
|
|
|
drvname);
|
2011-12-09 02:26:34 +00:00
|
|
|
return -1;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
2010-04-30 12:12:26 +00:00
|
|
|
/* don't tear anything while the address is being learned */
|
2011-11-03 09:21:35 +00:00
|
|
|
if (virNetDevGetIndex(net->ifname, &ifindex) < 0)
|
|
|
|
virResetLastError();
|
|
|
|
else if (virNWFilterLookupLearnReq(ifindex) != NULL)
|
2010-04-30 12:12:26 +00:00
|
|
|
return 0;
|
|
|
|
|
2011-11-23 19:13:03 +00:00
|
|
|
return techdriver->tearNewRules(net->ifname);
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-12-09 02:26:34 +00:00
|
|
|
static int
|
2011-11-23 19:13:03 +00:00
|
|
|
virNWFilterTearOldFilter(virDomainNetDefPtr net)
|
2010-03-25 17:46:09 +00:00
|
|
|
{
|
|
|
|
const char *drvname = EBIPTABLES_DRIVER_ID;
|
2010-04-30 12:12:26 +00:00
|
|
|
int ifindex;
|
2010-03-25 17:46:09 +00:00
|
|
|
virNWFilterTechDriverPtr techdriver;
|
2010-04-30 12:12:26 +00:00
|
|
|
|
2010-03-25 17:46:09 +00:00
|
|
|
techdriver = virNWFilterTechDriverForName(drvname);
|
|
|
|
if (!techdriver) {
|
2012-07-18 11:45:15 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("Could not get access to ACL tech "
|
|
|
|
"driver '%s'"),
|
|
|
|
drvname);
|
2011-12-09 02:26:34 +00:00
|
|
|
return -1;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
2010-04-30 12:12:26 +00:00
|
|
|
/* don't tear anything while the address is being learned */
|
2011-11-03 09:21:35 +00:00
|
|
|
if (virNetDevGetIndex(net->ifname, &ifindex) < 0)
|
|
|
|
virResetLastError();
|
|
|
|
else if (virNWFilterLookupLearnReq(ifindex) != NULL)
|
2010-04-30 12:12:26 +00:00
|
|
|
return 0;
|
|
|
|
|
2011-11-23 19:13:03 +00:00
|
|
|
return techdriver->tearOldRules(net->ifname);
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
static int
|
|
|
|
_virNWFilterTeardownFilter(const char *ifname)
|
2010-03-25 17:46:09 +00:00
|
|
|
{
|
|
|
|
const char *drvname = EBIPTABLES_DRIVER_ID;
|
|
|
|
virNWFilterTechDriverPtr techdriver;
|
|
|
|
techdriver = virNWFilterTechDriverForName(drvname);
|
|
|
|
|
|
|
|
if (!techdriver) {
|
2012-07-18 11:45:15 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("Could not get access to ACL tech "
|
|
|
|
"driver '%s'"),
|
|
|
|
drvname);
|
2011-12-09 02:26:34 +00:00
|
|
|
return -1;
|
2010-03-25 17:46:09 +00:00
|
|
|
}
|
2010-04-30 12:10:12 +00:00
|
|
|
|
2012-06-01 23:32:06 +00:00
|
|
|
virNWFilterDHCPSnoopEnd(ifname);
|
|
|
|
|
2010-04-30 12:10:12 +00:00
|
|
|
virNWFilterTerminateLearnReq(ifname);
|
|
|
|
|
2011-12-09 02:26:34 +00:00
|
|
|
if (virNWFilterLockIface(ifname) < 0)
|
2014-06-27 09:25:05 +00:00
|
|
|
return -1;
|
2010-04-30 12:10:12 +00:00
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
techdriver->allTeardown(ifname);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2012-06-01 23:32:06 +00:00
|
|
|
virNWFilterIPAddrMapDelIPAddr(ifname, NULL);
|
2010-03-25 17:46:09 +00:00
|
|
|
|
2010-04-30 12:10:12 +00:00
|
|
|
virNWFilterUnlockIface(ifname);
|
|
|
|
|
2010-03-25 17:46:09 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2010-03-30 14:25:22 +00:00
|
|
|
|
|
|
|
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
int
|
maint: avoid 'const fooPtr' in nwfilter files
'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can). But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).
Fix up offenders in nwfilter code.
This patch does nothing about the stupidity evident in having
__virNWFilterInstantiateFilter, _virNWFilterInstantiateFilter,
and virNWFilterInstantiateFilter, which differ only by leading
underscores, and which infringes on the namespace reserved to
the implementation - that would need to be a separate cleanup.
* src/nwfilter/nwfilter_dhcpsnoop.h (virNWFilterDHCPSnoopReq): Use
intended type.
* src/nwfilter/nwfilter_gentech_driver.h
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterInstantiataeFilterLate, virNWFilterTeardownFilter)
(virNWFilterCreateVarHashmap): Likewise.
* src/nwfilter/nwfilter_learnipaddr.h (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_conf.h (virNWFilterApplyBasicRules)
(virNWFilterApplyDHCPOnlyRules): Likewise.
(virNWFilterDefFormat): Make const-correct.
* src/conf/nwfilter_params.h (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple, virNWFilterVarValueGetCardinality)
(virNWFilterVarValueEqual, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarCombIterGetVarValue): Use intended type.
(virNWFilterVarValueGetNthValue): Make const-correct.
* src/nwfilter/nwfilter_dhcpsnoop.c (virNWFilterSnoopReqLeaseDel)
(virNWFilterSnoopIFKeyFMT, virNWFilterDHCPSnoopReq)
(virNWFilterSnoopPruneIter, virNWFilterSnoopRemAllReqIter)
(virNWFilterDHCPSnoopReq): Fix fallout.
* src/nwfilter/nwfilter_gentech_driver.c
(virNWFilterVarHashmapAddStdValues, virNWFilterCreateVarHashmap)
(virNWFilterInstantiate, __virNWFilterInstantiateFilter)
(_virNWFilterInstantiateFilter, virNWFilterInstantiateFilterLate)
(virNWFilterInstantiateFilter)
(virNWFilterUpdateInstantiateFilter)
(virNWFilterRollbackUpdateFilter, virNWFilterTeardownFilter):
Likewise.
* src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnIPAddress):
Likewise.
* src/conf/nwfilter_params.c (virNWFilterVarValueCopy)
(virNWFilterVarValueGetSimple)
(virNWFilterVarValueGetCardinality, virNWFilterVarValueEqual)
(virNWFilterVarCombIterAddVariable)
(virNWFilterVarCombIterGetVarValue, virNWFilterVarValueCompare)
(virNWFilterFormatParamAttributes, virNWFilterVarAccessEqual)
(virNWFilterVarAccessGetVarName, virNWFilterVarAccessGetType)
(virNWFilterVarAccessGetIterId, virNWFilterVarAccessGetIndex)
(virNWFilterVarAccessGetIntIterId)
(virNWFilterVarAccessIsAvailable)
(virNWFilterVarValueGetNthValue): Likewise.
* src/nwfilter/nwfilter_ebiptables_driver.c (ebtablesApplyBasicRules)
(ebtablesApplyDHCPOnlyRules, ebiptablesRuleOrderSort)
(ebiptablesRuleOrderSortPtr): Likewise.
* src/conf/nwfilter_conf.c (virNWFilterDefEqual)
(virNWFilterDefFormat): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-10-07 16:55:22 +00:00
|
|
|
virNWFilterTeardownFilter(const virDomainNetDef *net)
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
{
|
2014-01-22 18:13:30 +00:00
|
|
|
int ret;
|
|
|
|
virMutexLock(&updateMutex);
|
|
|
|
ret = _virNWFilterTeardownFilter(net->ifname);
|
|
|
|
virMutexUnlock(&updateMutex);
|
|
|
|
return ret;
|
nwfilter: Support for learning a VM's IP address
This patch implements support for learning a VM's IP address. It uses
the pcap library to listen on the VM's backend network interface (tap)
or the physical ethernet device (macvtap) and tries to capture packets
with source or destination MAC address of the VM and learn from DHCP
Offers, ARP traffic, or first-sent IPv4 packet what the IP address of
the VM's interface is. This then allows to instantiate the network
traffic filtering rules without the user having to provide the IP
parameter somewhere in the filter description or in the interface
description as a parameter. This only supports to detect the parameter
IP, which is for the assumed single IPv4 address of a VM. There is not
support for interfaces that may have multiple IP addresses (IP
aliasing) or IPv6 that may then require more than one valid IP address
to be detected. A VM can have multiple independent interfaces that each
uses a different IP address and in that case it will be attempted to
detect each one of the address independently.
So, when for example an interface description in the domain XML has
looked like this up to now:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'>
<parameter name='IP' value='10.2.3.4'/>
</filterref>
</interface>
you may omit the IP parameter:
<interface type='bridge'>
<source bridge='mybridge'/>
<model type='virtio'/>
<filterref filter='clean-traffic'/>
</interface>
Internally I am walking the 'tree' of a VM's referenced network filters
and determine with the given variables which variables are missing. Now,
the above IP parameter may be missing and this causes a libvirt-internal
thread to be started that uses the pcap library's API to listen to the
backend interface (in case of macvtap to the physical interface) in an
attempt to determine the missing IP parameter. If the backend interface
disappears the thread terminates assuming the VM was brought down. In
case of a macvtap device a timeout is being used to wait for packets
from the given VM (filtering by VM's interface MAC address). If the VM's
macvtap device disappeared the thread also terminates. In all other
cases it tries to determine the IP address of the VM and will then apply
the rules late on the given interface, which would have happened
immediately if the IP parameter had been explicitly given. In case an
error happens while the firewall rules are applied, the VM's backend
interface is 'down'ed preventing it to communicate. Reasons for failure
for applying the network firewall rules may that an ebtables/iptables
command failes or OOM errors. Essentially the same failure reasons may
occur as when the firewall rules are applied immediately on VM start,
except that due to the late application of the filtering rules the VM
now is already running and cannot be hindered anymore from starting.
Bringing down the whole VM would probably be considered too drastic.
While a VM's IP address is attempted to be determined only limited
updates to network filters are allowed. In particular it is prevented
that filters are modified in such a way that they would introduce new
variables.
A caveat: The algorithm does not know which one is the appropriate IP
address of a VM. If the VM spoofs an IP address in its first ARP traffic
or IPv4 packets its filtering rules will be instantiated for this IP
address, thus 'locking' it to the found IP address. So, it's still
'safer' to explicitly provide the IP address of a VM's interface in the
filter description if it is known beforehand.
* configure.ac: detect libpcap
* libvirt.spec.in: require libpcap[-devel] if qemu is built
* src/internal.h: add the new ATTRIBUTE_PACKED define
* src/Makefile.am src/libvirt_private.syms: add the new modules and symbols
* src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added
* src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch]
src/nwfilter/nwfilter_ebiptables_driver.[ch]
src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in
* tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-01-11 13:54:15 +00:00
|
|
|
int
|
|
|
|
virNWFilterDomainFWUpdateCB(virDomainObjPtr obj,
|
2010-03-30 14:25:22 +00:00
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
virDomainDefPtr vm = obj->def;
|
|
|
|
struct domUpdateCBStruct *cb = data;
|
Convert 'int i' to 'size_t i' in src/nwfilter/ files
Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-08 14:09:33 +00:00
|
|
|
size_t i;
|
2010-05-03 22:14:58 +00:00
|
|
|
bool skipIface;
|
2013-01-11 13:54:15 +00:00
|
|
|
int ret = 0;
|
2010-03-30 14:25:22 +00:00
|
|
|
|
2013-01-09 21:00:32 +00:00
|
|
|
virObjectLock(obj);
|
2010-03-30 14:25:22 +00:00
|
|
|
|
|
|
|
if (virDomainObjIsActive(obj)) {
|
|
|
|
for (i = 0; i < vm->nnets; i++) {
|
|
|
|
virDomainNetDefPtr net = vm->nets[i];
|
|
|
|
if ((net->filter) && (net->ifname)) {
|
|
|
|
switch (cb->step) {
|
|
|
|
case STEP_APPLY_NEW:
|
2013-10-03 11:45:26 +00:00
|
|
|
ret = virNWFilterUpdateInstantiateFilter(cb->opaque,
|
2013-01-11 13:54:15 +00:00
|
|
|
vm->uuid,
|
|
|
|
net,
|
|
|
|
&skipIface);
|
|
|
|
if (ret == 0 && skipIface) {
|
2011-01-28 21:38:06 +00:00
|
|
|
/* filter tree unchanged -- no update needed */
|
2013-01-11 13:54:15 +00:00
|
|
|
ret = virHashAddEntry(cb->skipInterfaces,
|
|
|
|
net->ifname,
|
|
|
|
(void *)~0);
|
2010-05-03 22:14:58 +00:00
|
|
|
}
|
2010-03-30 14:25:22 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case STEP_TEAR_NEW:
|
2014-11-13 14:27:11 +00:00
|
|
|
if (!virHashLookup(cb->skipInterfaces, net->ifname))
|
2013-01-11 13:54:15 +00:00
|
|
|
ret = virNWFilterRollbackUpdateFilter(net);
|
2010-03-30 14:25:22 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case STEP_TEAR_OLD:
|
2014-11-13 14:27:11 +00:00
|
|
|
if (!virHashLookup(cb->skipInterfaces, net->ifname))
|
2013-01-11 13:54:15 +00:00
|
|
|
ret = virNWFilterTearOldFilter(net);
|
2010-03-30 14:25:22 +00:00
|
|
|
break;
|
2012-01-27 13:19:58 +00:00
|
|
|
|
|
|
|
case STEP_APPLY_CURRENT:
|
2013-10-03 11:45:26 +00:00
|
|
|
ret = virNWFilterInstantiateFilter(cb->opaque,
|
2012-01-27 13:19:58 +00:00
|
|
|
vm->uuid,
|
|
|
|
net);
|
2013-01-11 13:54:15 +00:00
|
|
|
if (ret)
|
2012-07-18 11:45:15 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
_("Failure while applying current filter on "
|
|
|
|
"VM %s"), vm->name);
|
2012-01-27 13:19:58 +00:00
|
|
|
break;
|
2010-03-30 14:25:22 +00:00
|
|
|
}
|
2013-01-11 13:54:15 +00:00
|
|
|
if (ret)
|
2010-03-30 14:25:22 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-01-09 21:00:32 +00:00
|
|
|
virObjectUnlock(obj);
|
2013-01-11 13:54:15 +00:00
|
|
|
return ret;
|
2010-03-30 14:25:22 +00:00
|
|
|
}
|