libvirt/src/nwfilter/nwfilter_gentech_driver.c

1115 lines
34 KiB
C
Raw Normal View History

/*
* nwfilter_gentech_driver.c: generic technology driver
*
* Copyright (C) 2011-2014 Red Hat, Inc.
* 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
* License along with this library. If not, see
* <http://www.gnu.org/licenses/>.
*
* 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"
#include "domain_conf.h"
#include "virerror.h"
#include "nwfilter_gentech_driver.h"
#include "nwfilter_ebiptables_driver.h"
#include "nwfilter_dhcpsnoop.h"
#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"
#include "virnetdev.h"
#include "datatypes.h"
#include "virsocketaddr.h"
#include "virstring.h"
#define VIR_FROM_THIS VIR_FROM_NWFILTER
VIR_LOG_INIT("nwfilter.nwfilter_gentech_driver");
#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);
static virNWFilterTechDriverPtr filter_tech_drivers[] = {
&ebiptables_driver,
NULL
};
/* Serializes instantiation of filters. This is necessary
* to avoid lock ordering deadlocks. eg virNWFilterInstantiateFilterUpdate
* will hold a lock on a virNWFilterObjPtr. This in turn invokes
* virNWFilterDoInstantiate which invokes virNWFilterDetermineMissingVarsRec
* 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.
*
* 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;
int virNWFilterTechDriversInit(bool privileged)
{
size_t i = 0;
VIR_DEBUG("Initializing NWFilter technology drivers");
if (virMutexInitRecursive(&updateMutex) < 0)
return -1;
while (filter_tech_drivers[i]) {
if (!(filter_tech_drivers[i]->flags & TECHDRV_FLAG_INITIALIZED))
filter_tech_drivers[i]->init(privileged);
i++;
}
return 0;
}
void virNWFilterTechDriversShutdown(void)
{
size_t i = 0;
while (filter_tech_drivers[i]) {
if ((filter_tech_drivers[i]->flags & TECHDRV_FLAG_INITIALIZED))
filter_tech_drivers[i]->shutdown();
i++;
}
virMutexDestroy(&updateMutex);
}
virNWFilterTechDriverPtr
virNWFilterTechDriverForName(const char *name)
{
size_t i = 0;
while (filter_tech_drivers[i]) {
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++;
}
return NULL;
}
static void
virNWFilterRuleInstFree(virNWFilterRuleInstPtr inst)
{
if (!inst)
return;
virNWFilterHashTableFree(inst->vars);
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
*
* Returns 0 in case of success, -1 in case an error happened with
* error having been reported.
*
* Adds a couple of standard keys (MAC, IP) to the hash table.
*/
static int
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)
{
virNWFilterVarValue *val;
if (macaddr) {
val = virNWFilterVarValueCreateSimple(macaddr);
if (!val)
return -1;
if (virHashAddEntry(table->hashTable,
NWFILTER_STD_VAR_MAC,
val) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
"%s", _("Could not add variable 'MAC' to hashmap"));
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
if (ipaddr) {
val = virNWFilterVarValueCopy(ipaddr);
if (!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
if (virHashAddEntry(table->hashTable,
NWFILTER_STD_VAR_IP,
val) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
"%s", _("Could not add variable 'IP' to hashmap"));
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
}
}
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
*
* 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.
*
* Returns pointer to hashmap, NULL if an error occurred.
*/
virNWFilterHashTablePtr
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)
{
virNWFilterHashTablePtr table = virNWFilterHashTableCreate(0);
if (!table)
return NULL;
if (virNWFilterVarHashmapAddStdValues(table, macaddr, ipaddr) < 0) {
virNWFilterHashTableFree(table);
return NULL;
}
return table;
}
/**
* Convert a virNWFilterHashTable into a string of comma-separated
* variable names.
*/
struct printString
{
virBuffer buf;
const char *separator;
bool reportMAC;
bool reportIP;
};
static int
printString(void *payload ATTRIBUTE_UNUSED, const void *name, void *data)
{
struct printString *ps = data;
if ((STREQ((char *)name, NWFILTER_STD_VAR_IP) && !ps->reportIP) ||
(STREQ((char *)name, NWFILTER_STD_VAR_MAC) && !ps->reportMAC))
return 0;
if (virBufferUse(&ps->buf) && ps->separator)
virBufferAdd(&ps->buf, ps->separator, -1);
virBufferAdd(&ps->buf, name, -1);
return 0;
}
/**
* 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)
{
struct printString ps = {
.buf = VIR_BUFFER_INITIALIZER,
.separator = separator,
.reportMAC = reportMAC,
.reportIP = reportIP,
};
virHashForEach(vars, printString, &ps);
if (virBufferCheckError(&ps.buf) < 0)
return NULL;
return virBufferContentAndReset(&ps.buf);
}
/**
* 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
virNWFilterCreateVarsFrom(virNWFilterHashTablePtr vars1,
virNWFilterHashTablePtr vars2)
{
virNWFilterHashTablePtr res = virNWFilterHashTableCreate(0);
if (!res)
return NULL;
if (virNWFilterHashTablePutAll(vars1, res) < 0)
goto err_exit;
if (virNWFilterHashTablePutAll(vars2, res) < 0)
goto err_exit;
return res;
err_exit:
virNWFilterHashTableFree(res);
return NULL;
}
typedef struct _virNWFilterInst virNWFilterInst;
typedef virNWFilterInst *virNWFilterInstPtr;
struct _virNWFilterInst {
virNWFilterObjPtr *filters;
size_t nfilters;
virNWFilterRuleInstPtr *rules;
size_t nrules;
};
static void
virNWFilterInstReset(virNWFilterInstPtr inst)
{
size_t i;
for (i = 0; i < inst->nfilters; i++)
virNWFilterObjUnlock(inst->filters[i]);
VIR_FREE(inst->filters);
inst->nfilters = 0;
for (i = 0; i < inst->nrules; i++)
virNWFilterRuleInstFree(inst->rules[i]);
VIR_FREE(inst->rules);
}
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;
virNWFilterDefPtr newChilddef;
int ret = -1;
VIR_DEBUG("Instantiating filter %s", inc->filterref);
if (!(obj = virNWFilterObjListFindInstantiateFilter(driver->nwfilters,
inc->filterref)))
goto cleanup;
/* create a temporary hashmap for depth-first tree traversal */
if (!(tmpvars = virNWFilterCreateVarsFrom(inc->params,
vars)))
goto cleanup;
childdef = virNWFilterObjGetDef(obj);
switch (useNewFilter) {
case INSTANTIATE_FOLLOW_NEWFILTER:
newChilddef = virNWFilterObjGetNewDef(obj);
if (newChilddef) {
childdef = newChilddef;
*foundNewFilter = true;
}
break;
case INSTANTIATE_ALWAYS:
break;
}
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
/**
* 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
}
}
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
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)
{
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;
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;
virNWFilterDefPtr newNext_filter;
virNWFilterVarValuePtr val;
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) {
/* check all variables of this rule */
for (j = 0; j < rule->nVarAccess; j++) {
if (!virNWFilterVarAccessIsAvailable(rule->varAccess[j],
vars)) {
char *varAccess;
virBuffer buf = VIR_BUFFER_INITIALIZER;
virNWFilterVarAccessPrint(rule->varAccess[j], &buf);
if (virBufferError(&buf)) {
virReportOOMError();
return -1;
}
val = virNWFilterVarValueCreateSimpleCopyValue("1");
if (!val) {
virBufferFreeAndReset(&buf);
return -1;
}
varAccess = virBufferContentAndReset(&buf);
rc = virNWFilterHashTablePut(missing_vars, varAccess, val);
VIR_FREE(varAccess);
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) {
VIR_DEBUG("Following filter %s", inc->filterref);
if (!(obj = virNWFilterObjListFindInstantiateFilter(driver->nwfilters,
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
/* create a temporary hashmap for depth-first tree traversal */
if (!(tmpvars = virNWFilterCreateVarsFrom(inc->params, vars))) {
virNWFilterObjUnlock(obj);
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
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
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
rc = virNWFilterDetermineMissingVarsRec(next_filter,
tmpvars,
missing_vars,
useNewFilter,
driver);
virNWFilterHashTableFree(tmpvars);
virNWFilterObjUnlock(obj);
if (rc < 0)
return -1;
}
}
return 0;
}
/**
* virNWFilterDoInstantiate:
* @vmuuid: The UUID of the VM
* @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.
* @forceWithPendingReq: Ignore the check whether a pending learn request
* is active; 'true' only when the rules are applied late
*
* 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.
*
* Call this function while holding the NWFilter filter update lock
*/
static int
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)
{
int rc;
virNWFilterInst inst;
bool instantiate = true;
char *buf;
virNWFilterVarValuePtr lv;
const char *learning;
bool reportIP = false;
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);
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) {
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;
}
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);
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;
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) {
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
}
if (STRCASEEQ(learning, "dhcp")) {
rc = virNWFilterDHCPSnoopReq(techdriver, ifname, linkdev,
vmuuid, macaddr,
filter->name, vars, driver);
goto err_exit;
} else if (STRCASEEQ(learning, "any")) {
if (virNWFilterLookupLearnReq(ifindex) == NULL) {
rc = virNWFilterLearnIPAddress(techdriver,
ifname,
ifindex,
linkdev,
macaddr,
filter->name,
vars, driver,
DETECT_DHCP|DETECT_STATIC);
}
goto err_exit;
} else {
rc = -1;
virReportError(VIR_ERR_PARSE_FAILED,
_("filter '%s' "
"learning value '%s' invalid."),
filter->name, learning);
goto err_exit;
}
} else {
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
} else if (virHashSize(missing_vars->hashTable) > 1) {
goto err_unresolvable_vars;
} else if (!forceWithPendingReq &&
virNWFilterLookupLearnReq(ifindex) != NULL) {
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
}
rc = virNWFilterDefToInst(driver,
filter,
vars,
useNewFilter, foundNewFilter,
&inst);
if (rc < 0)
goto err_exit;
switch (useNewFilter) {
case INSTANTIATE_FOLLOW_NEWFILTER:
instantiate = *foundNewFilter;
break;
case INSTANTIATE_ALWAYS:
instantiate = true;
break;
}
if (instantiate) {
if (virNWFilterLockIface(ifname) < 0)
Changes from V1 to V2: - using INT_BUFSIZE_BOUND() to determine the length of the buffersize for printing and integer into - not explicitly initializing static var threadsTerminate to false anymore, since that's done automatically Changes after V2: - removed while looks in case of OOM error - removed on ifaceDown() call - preceding one ifaceDown() call with an ifaceCheck() call Since the name of an interface can be the same between stops and starts of different VMs I have to switch the IP address learning thread to use the index of the interface to determine whether an interface is still available or not - in the case of macvtap the thread needs to listen for traffic on the physical interface, thus having to time out periodically to check whether the VM's macvtap device is still there as an indication that the VM is still alive. Previously the following sequence of 2 VMs with macvtap device virsh start testvm1; virsh destroy testvm1 ; virsh start testvm2 would not terminate the thread upon testvm1's destroy since the name of the interface on the host could be the same (i.e, macvtap0) on testvm1 and testvm2, thus it was easily race-able. The thread would then determine the IP address parameter for testvm2 but apply the rule set for testvm1. :-( I am also introducing a lock for the interface (by name) that the thread must hold while it listens for the traffic and releases when it terminates upon VM termination or 0.5 second thereafter. Thus, the new thread for a newly started VM with the same interface name will not start while the old one still holds the lock. The only other code that I see that also needs to grab the lock to serialize operation is the one that tears down the firewall that were established on behalf of an interface. I am moving the code applying the 'basic' firewall rules during the IP address learning phase inside the thread but won't start the thread unless it is ensured that the firewall driver has the ability to apply the 'basic' firewall rules.
2010-04-22 18:58:57 +00:00
goto err_exit;
rc = techdriver->applyNewRules(ifname, inst.rules, inst.nrules);
if (teardownOld && rc == 0)
techdriver->tearOldRules(ifname);
if (rc == 0 && (virNetDevValidateConfig(ifname, NULL, ifindex) <= 0)) {
virResetLastError();
Changes from V1 to V2: - using INT_BUFSIZE_BOUND() to determine the length of the buffersize for printing and integer into - not explicitly initializing static var threadsTerminate to false anymore, since that's done automatically Changes after V2: - removed while looks in case of OOM error - removed on ifaceDown() call - preceding one ifaceDown() call with an ifaceCheck() call Since the name of an interface can be the same between stops and starts of different VMs I have to switch the IP address learning thread to use the index of the interface to determine whether an interface is still available or not - in the case of macvtap the thread needs to listen for traffic on the physical interface, thus having to time out periodically to check whether the VM's macvtap device is still there as an indication that the VM is still alive. Previously the following sequence of 2 VMs with macvtap device virsh start testvm1; virsh destroy testvm1 ; virsh start testvm2 would not terminate the thread upon testvm1's destroy since the name of the interface on the host could be the same (i.e, macvtap0) on testvm1 and testvm2, thus it was easily race-able. The thread would then determine the IP address parameter for testvm2 but apply the rule set for testvm1. :-( I am also introducing a lock for the interface (by name) that the thread must hold while it listens for the traffic and releases when it terminates upon VM termination or 0.5 second thereafter. Thus, the new thread for a newly started VM with the same interface name will not start while the old one still holds the lock. The only other code that I see that also needs to grab the lock to serialize operation is the one that tears down the firewall that were established on behalf of an interface. I am moving the code applying the 'basic' firewall rules during the IP address learning phase inside the thread but won't start the thread unless it is ensured that the firewall driver has the ability to apply the 'basic' firewall rules.
2010-04-22 18:58:57 +00:00
/* interface changed/disppeared */
techdriver->allTeardown(ifname);
rc = -1;
Changes from V1 to V2: - using INT_BUFSIZE_BOUND() to determine the length of the buffersize for printing and integer into - not explicitly initializing static var threadsTerminate to false anymore, since that's done automatically Changes after V2: - removed while looks in case of OOM error - removed on ifaceDown() call - preceding one ifaceDown() call with an ifaceCheck() call Since the name of an interface can be the same between stops and starts of different VMs I have to switch the IP address learning thread to use the index of the interface to determine whether an interface is still available or not - in the case of macvtap the thread needs to listen for traffic on the physical interface, thus having to time out periodically to check whether the VM's macvtap device is still there as an indication that the VM is still alive. Previously the following sequence of 2 VMs with macvtap device virsh start testvm1; virsh destroy testvm1 ; virsh start testvm2 would not terminate the thread upon testvm1's destroy since the name of the interface on the host could be the same (i.e, macvtap0) on testvm1 and testvm2, thus it was easily race-able. The thread would then determine the IP address parameter for testvm2 but apply the rule set for testvm1. :-( I am also introducing a lock for the interface (by name) that the thread must hold while it listens for the traffic and releases when it terminates upon VM termination or 0.5 second thereafter. Thus, the new thread for a newly started VM with the same interface name will not start while the old one still holds the lock. The only other code that I see that also needs to grab the lock to serialize operation is the one that tears down the firewall that were established on behalf of an interface. I am moving the code applying the 'basic' firewall rules during the IP address learning phase inside the thread but won't start the thread unless it is ensured that the firewall driver has the ability to apply the 'basic' firewall rules.
2010-04-22 18:58:57 +00:00
}
virNWFilterUnlockIface(ifname);
}
err_exit:
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);
return rc;
err_unresolvable_vars:
buf = virNWFilterPrintVars(missing_vars->hashTable, ", ", false, reportIP);
if (buf) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Cannot instantiate filter due to unresolvable "
"variables or unavailable list elements: %s"), buf);
VIR_FREE(buf);
}
rc = -1;
goto err_exit;
}
/*
* Call this function while holding the NWFilter filter update lock
*/
static int
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)
{
int rc;
const char *drvname = EBIPTABLES_DRIVER_ID;
virNWFilterTechDriverPtr techdriver;
virNWFilterObjPtr obj;
virNWFilterHashTablePtr vars, vars1;
virNWFilterDefPtr filter;
virNWFilterDefPtr newFilter;
char vmmacaddr[VIR_MAC_STRING_BUFLEN] = {0};
char *str_macaddr = NULL;
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;
techdriver = virNWFilterTechDriverForName(drvname);
if (!techdriver) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Could not get access to ACL tech "
"driver '%s'"),
drvname);
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
VIR_DEBUG("filter name: %s", filtername);
if (!(obj = virNWFilterObjListFindInstantiateFilter(driver->nwfilters,
filtername)))
return -1;
virMacAddrFormat(macaddr, vmmacaddr);
if (VIR_STRDUP(str_macaddr, vmmacaddr) < 0) {
rc = -1;
goto err_exit;
}
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
vars1 = virNWFilterCreateVarHashmap(str_macaddr, ipaddr);
if (!vars1) {
rc = -1;
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;
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);
if (!vars) {
rc = -1;
goto err_exit_vars1;
}
filter = virNWFilterObjGetDef(obj);
switch (useNewFilter) {
case INSTANTIATE_FOLLOW_NEWFILTER:
newFilter = virNWFilterObjGetNewDef(obj);
if (newFilter) {
filter = newFilter;
*foundNewFilter = true;
}
break;
case INSTANTIATE_ALWAYS:
break;
}
rc = virNWFilterDoInstantiate(vmuuid, techdriver, filter,
ifname, ifindex, linkdev,
vars, useNewFilter, foundNewFilter,
teardownOld, macaddr, driver,
forceWithPendingReq);
virNWFilterHashTableFree(vars);
err_exit_vars1:
virNWFilterHashTableFree(vars1);
err_exit:
virNWFilterObjUnlock(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
VIR_FREE(str_ipaddr);
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
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;
Changes from V1 to V2: - using INT_BUFSIZE_BOUND() to determine the length of the buffersize for printing and integer into - not explicitly initializing static var threadsTerminate to false anymore, since that's done automatically Changes after V2: - removed while looks in case of OOM error - removed on ifaceDown() call - preceding one ifaceDown() call with an ifaceCheck() call Since the name of an interface can be the same between stops and starts of different VMs I have to switch the IP address learning thread to use the index of the interface to determine whether an interface is still available or not - in the case of macvtap the thread needs to listen for traffic on the physical interface, thus having to time out periodically to check whether the VM's macvtap device is still there as an indication that the VM is still alive. Previously the following sequence of 2 VMs with macvtap device virsh start testvm1; virsh destroy testvm1 ; virsh start testvm2 would not terminate the thread upon testvm1's destroy since the name of the interface on the host could be the same (i.e, macvtap0) on testvm1 and testvm2, thus it was easily race-able. The thread would then determine the IP address parameter for testvm2 but apply the rule set for testvm1. :-( I am also introducing a lock for the interface (by name) that the thread must hold while it listens for the traffic and releases when it terminates upon VM termination or 0.5 second thereafter. Thus, the new thread for a newly started VM with the same interface name will not start while the old one still holds the lock. The only other code that I see that also needs to grab the lock to serialize operation is the one that tears down the firewall that were established on behalf of an interface. I am moving the code applying the 'basic' firewall rules during the IP address learning phase inside the thread but won't start the thread unless it is ensured that the firewall driver has the ability to apply the 'basic' firewall rules.
2010-04-22 18:58:57 +00:00
int ifindex;
int rc;
Changes from V1 to V2: - using INT_BUFSIZE_BOUND() to determine the length of the buffersize for printing and integer into - not explicitly initializing static var threadsTerminate to false anymore, since that's done automatically Changes after V2: - removed while looks in case of OOM error - removed on ifaceDown() call - preceding one ifaceDown() call with an ifaceCheck() call Since the name of an interface can be the same between stops and starts of different VMs I have to switch the IP address learning thread to use the index of the interface to determine whether an interface is still available or not - in the case of macvtap the thread needs to listen for traffic on the physical interface, thus having to time out periodically to check whether the VM's macvtap device is still there as an indication that the VM is still alive. Previously the following sequence of 2 VMs with macvtap device virsh start testvm1; virsh destroy testvm1 ; virsh start testvm2 would not terminate the thread upon testvm1's destroy since the name of the interface on the host could be the same (i.e, macvtap0) on testvm1 and testvm2, thus it was easily race-able. The thread would then determine the IP address parameter for testvm2 but apply the rule set for testvm1. :-( I am also introducing a lock for the interface (by name) that the thread must hold while it listens for the traffic and releases when it terminates upon VM termination or 0.5 second thereafter. Thus, the new thread for a newly started VM with the same interface name will not start while the old one still holds the lock. The only other code that I see that also needs to grab the lock to serialize operation is the one that tears down the firewall that were established on behalf of an interface. I am moving the code applying the 'basic' firewall rules during the IP address learning phase inside the thread but won't start the thread unless it is ensured that the firewall driver has the ability to apply the 'basic' firewall rules.
2010-04-22 18:58:57 +00:00
virMutexLock(&updateMutex);
/* 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 */
if (virNetDevExists(net->ifname) != 1 ||
virNetDevGetIndex(net->ifname, &ifindex) < 0) {
/* interfaces / VMs can disappear during filter instantiation;
don't mark it as an error */
virResetLastError();
rc = 0;
goto cleanup;
}
rc = virNWFilterInstantiateFilterUpdate(driver, vmuuid, teardownOld,
net->ifname, ifindex, linkdev,
&net->mac, net->filter,
net->filterparams, useNewFilter,
false, foundNewFilter);
cleanup:
virMutexUnlock(&updateMutex);
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
virNWFilterInstantiateFilterLate(virNWFilterDriverStatePtr driver,
const unsigned char *vmuuid,
const char *ifname,
Changes from V1 to V2: - using INT_BUFSIZE_BOUND() to determine the length of the buffersize for printing and integer into - not explicitly initializing static var threadsTerminate to false anymore, since that's done automatically Changes after V2: - removed while looks in case of OOM error - removed on ifaceDown() call - preceding one ifaceDown() call with an ifaceCheck() call Since the name of an interface can be the same between stops and starts of different VMs I have to switch the IP address learning thread to use the index of the interface to determine whether an interface is still available or not - in the case of macvtap the thread needs to listen for traffic on the physical interface, thus having to time out periodically to check whether the VM's macvtap device is still there as an indication that the VM is still alive. Previously the following sequence of 2 VMs with macvtap device virsh start testvm1; virsh destroy testvm1 ; virsh start testvm2 would not terminate the thread upon testvm1's destroy since the name of the interface on the host could be the same (i.e, macvtap0) on testvm1 and testvm2, thus it was easily race-able. The thread would then determine the IP address parameter for testvm2 but apply the rule set for testvm1. :-( I am also introducing a lock for the interface (by name) that the thread must hold while it listens for the traffic and releases when it terminates upon VM termination or 0.5 second thereafter. Thus, the new thread for a newly started VM with the same interface name will not start while the old one still holds the lock. The only other code that I see that also needs to grab the lock to serialize operation is the one that tears down the firewall that were established on behalf of an interface. I am moving the code applying the 'basic' firewall rules during the IP address learning phase inside the thread but won't start the thread unless it is ensured that the firewall driver has the ability to apply the 'basic' firewall rules.
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,
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;
bool foundNewFilter = false;
Push nwfilter update locking up to top level The NWFilter code has as a deadlock race condition between the virNWFilter{Define,Undefine} APIs and starting of guest VMs due to mis-matched lock ordering. In the virNWFilter{Define,Undefine} codepaths the lock ordering is 1. nwfilter driver lock 2. virt driver lock 3. nwfilter update lock 4. domain object lock In the VM guest startup paths the lock ordering is 1. virt driver lock 2. domain object lock 3. nwfilter update lock As can be seen the domain object and nwfilter update locks are not acquired in a consistent order. The fix used is to push the nwfilter update lock upto the top level resulting in a lock ordering for virNWFilter{Define,Undefine} of 1. nwfilter driver lock 2. nwfilter update lock 3. virt driver lock 4. domain object lock and VM start using 1. nwfilter update lock 2. virt driver lock 3. domain object lock This has the effect of serializing VM startup once again, even if no nwfilters are applied to the guest. There is also the possibility of deadlock due to a call graph loop via virNWFilterInstantiate and virNWFilterInstantiateFilterLate. These two problems mean the lock must be turned into a read/write lock instead of a plain mutex at the same time. The lock is used to serialize changes to the "driver->nwfilters" hash, so the write lock only needs to be held by the define/undefine methods. All other methods can rely on a read lock which allows good concurrency. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-01-22 17:28:29 +00:00
virNWFilterReadLockFilterUpdates();
virMutexLock(&updateMutex);
rc = virNWFilterInstantiateFilterUpdate(driver, vmuuid, true,
ifname, ifindex, linkdev,
macaddr, filtername, filterparams,
INSTANTIATE_ALWAYS, true,
&foundNewFilter);
if (rc < 0) {
/* something went wrong... 'DOWN' the interface */
if ((virNetDevValidateConfig(ifname, NULL, ifindex) <= 0) ||
(virNetDevSetOnline(ifname, false) < 0)) {
virResetLastError();
/* 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);
}
}
virNWFilterUnlockFilterUpdates();
virMutexUnlock(&updateMutex);
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;
}
int
virNWFilterInstantiateFilter(virNWFilterDriverStatePtr driver,
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)
{
bool foundNewFilter = false;
return virNWFilterInstantiateFilterInternal(driver, vmuuid, net,
1,
INSTANTIATE_ALWAYS,
&foundNewFilter);
}
int
virNWFilterUpdateInstantiateFilter(virNWFilterDriverStatePtr driver,
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,
bool *skipIface)
{
bool foundNewFilter = false;
int rc = virNWFilterInstantiateFilterInternal(driver, vmuuid, net,
0,
INSTANTIATE_FOLLOW_NEWFILTER,
&foundNewFilter);
*skipIface = !foundNewFilter;
return rc;
}
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)
{
const char *drvname = EBIPTABLES_DRIVER_ID;
int ifindex;
virNWFilterTechDriverPtr techdriver;
techdriver = virNWFilterTechDriverForName(drvname);
if (!techdriver) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Could not get access to ACL tech "
"driver '%s'"),
drvname);
return -1;
}
/* don't tear anything while the address is being learned */
if (virNetDevGetIndex(net->ifname, &ifindex) < 0)
virResetLastError();
else if (virNWFilterLookupLearnReq(ifindex) != NULL)
return 0;
return techdriver->tearNewRules(net->ifname);
}
static int
virNWFilterTearOldFilter(virDomainNetDefPtr net)
{
const char *drvname = EBIPTABLES_DRIVER_ID;
int ifindex;
virNWFilterTechDriverPtr techdriver;
techdriver = virNWFilterTechDriverForName(drvname);
if (!techdriver) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Could not get access to ACL tech "
"driver '%s'"),
drvname);
return -1;
}
/* don't tear anything while the address is being learned */
if (virNetDevGetIndex(net->ifname, &ifindex) < 0)
virResetLastError();
else if (virNWFilterLookupLearnReq(ifindex) != NULL)
return 0;
return techdriver->tearOldRules(net->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
static int
_virNWFilterTeardownFilter(const char *ifname)
{
const char *drvname = EBIPTABLES_DRIVER_ID;
virNWFilterTechDriverPtr techdriver;
techdriver = virNWFilterTechDriverForName(drvname);
if (!techdriver) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Could not get access to ACL tech "
"driver '%s'"),
drvname);
return -1;
}
virNWFilterDHCPSnoopEnd(ifname);
virNWFilterTerminateLearnReq(ifname);
if (virNWFilterLockIface(ifname) < 0)
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
techdriver->allTeardown(ifname);
virNWFilterIPAddrMapDelIPAddr(ifname, NULL);
virNWFilterUnlockIface(ifname);
return 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
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
{
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
}
int
virNWFilterDomainFWUpdateCB(virDomainObjPtr obj,
void *data)
{
virDomainDefPtr vm = obj->def;
struct domUpdateCBStruct *cb = data;
size_t i;
bool skipIface;
int ret = 0;
virObjectLock(obj);
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:
ret = virNWFilterUpdateInstantiateFilter(cb->opaque,
vm->uuid,
net,
&skipIface);
if (ret == 0 && skipIface) {
/* filter tree unchanged -- no update needed */
ret = virHashAddEntry(cb->skipInterfaces,
net->ifname,
(void *)~0);
}
break;
case STEP_TEAR_NEW:
if (!virHashLookup(cb->skipInterfaces, net->ifname))
ret = virNWFilterRollbackUpdateFilter(net);
break;
case STEP_TEAR_OLD:
if (!virHashLookup(cb->skipInterfaces, net->ifname))
ret = virNWFilterTearOldFilter(net);
break;
case STEP_APPLY_CURRENT:
ret = virNWFilterInstantiateFilter(cb->opaque,
vm->uuid,
net);
if (ret)
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failure while applying current filter on "
"VM %s"), vm->name);
break;
}
if (ret)
break;
}
}
}
virObjectUnlock(obj);
return ret;
}