| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aMCcnO4rJdDIdx3m@calendula>
Date: Tue, 9 Sep 2025 23:31:08 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Lorenzo Bianconi <lorenzo@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>,
David Ahern <dsahern@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>,
Jozsef Kadlecsik <kadlec@...filter.org>,
Shuah Khan <shuah@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>,
Florian Westphal <fw@...len.de>, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH nf-next v6 1/2] net: netfilter: Add IPIP flowtable SW
acceleration
On Mon, Aug 18, 2025 at 11:07:33AM +0200, Lorenzo Bianconi wrote:
> Introduce SW acceleration for IPIP tunnels in the netfilter flowtable
> infrastructure.
> IPIP SW acceleration can be tested running the following scenario where
> the traffic is forwarded between two NICs (eth0 and eth1) and an IPIP
> tunnel is used to access a remote site (using eth1 as the underlay device):
>
> ETH0 -- TUN0 <==> ETH1 -- [IP network] -- TUN1 (192.168.100.2)
>
> $ip addr show
> 6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
> link/ether 00:00:22:33:11:55 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.2/24 scope global eth0
> valid_lft forever preferred_lft forever
> 7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
> link/ether 00:11:22:33:11:55 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global eth1
> valid_lft forever preferred_lft forever
> 8: tun0@...E: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
> link/ipip 192.168.1.1 peer 192.168.1.2
> inet 192.168.100.1/24 scope global tun0
> valid_lft forever preferred_lft forever
>
> $ip route show
> default via 192.168.100.2 dev tun0
> 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2
> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
> 192.168.100.0/24 dev tun0 proto kernel scope link src 192.168.100.1
>
> $nft list ruleset
> table inet filter {
> flowtable ft {
> hook ingress priority filter
> devices = { eth0, eth1 }
> }
>
> chain forward {
> type filter hook forward priority filter; policy accept;
> meta l4proto { tcp, udp } flow add @ft
> }
> }
>
> Reproducing the scenario described above using veths I got the following
> results:
> - TCP stream transmitted into the IPIP tunnel:
> - net-next: ~41Gbps
> - net-next + IPIP flowtbale support: ~40Gbps
I found this patch in one of my trees (see attachment) to explore
tunnel integration of the tx path, there has been similar patches
floating on the mailing list for layer 2 encapsulation (eg. pppoe and
vlan), IIRC for pppoe I remember they claim to accelerate tx.
Another aspect of this series is that I think it would be good to
explore integration of other layer 3 tunnel protocols, rather than
following an incremental approach.
More comments below.
> - TCP stream received from the IPIP tunnel:
> - net-next: ~35Gbps
> - net-next + IPIP flowtbale support: ~49Gbps
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@...nel.org>
> ---
> include/linux/netdevice.h | 1 +
> net/ipv4/ipip.c | 28 ++++++++++++++++++++
> net/netfilter/nf_flow_table_ip.c | 56 ++++++++++++++++++++++++++++++++++++++--
> net/netfilter/nft_flow_offload.c | 1 +
> 4 files changed, 84 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index f3a3b761abfb1b883a970b04634c1ef3e7ee5407..0527a4e3d1fd512b564e47311f6ce3957b66298f 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -874,6 +874,7 @@ enum net_device_path_type {
> DEV_PATH_PPPOE,
> DEV_PATH_DSA,
> DEV_PATH_MTK_WDMA,
> + DEV_PATH_IPENCAP,
> };
>
> struct net_device_path {
> diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
> index 3e03af073a1ccc3d7597a998a515b6cfdded40b5..b7a3311bd061c341987380b5872caa8990d02e63 100644
> --- a/net/ipv4/ipip.c
> +++ b/net/ipv4/ipip.c
> @@ -353,6 +353,33 @@ ipip_tunnel_ctl(struct net_device *dev, struct ip_tunnel_parm_kern *p, int cmd)
> return ip_tunnel_ctl(dev, p, cmd);
> }
>
> +static int ipip_fill_forward_path(struct net_device_path_ctx *ctx,
> + struct net_device_path *path)
> +{
> + struct ip_tunnel *tunnel = netdev_priv(ctx->dev);
> + const struct iphdr *tiph = &tunnel->parms.iph;
> + struct rtable *rt;
> +
> + rt = ip_route_output(dev_net(ctx->dev), tiph->daddr, 0, 0, 0,
> + RT_SCOPE_UNIVERSE);
> + if (IS_ERR(rt))
> + return PTR_ERR(rt);
> +
> + path->type = DEV_PATH_IPENCAP;
> + path->dev = ctx->dev;
> + path->encap.proto = htons(ETH_P_IP);
> + /* Use the hash of outer header IP src and dst addresses as
> + * encapsulation ID. This must be kept in sync with
> + * nf_flow_tuple_encap().
> + */
> + path->encap.id = __ipv4_addr_hash(tiph->saddr, ntohl(tiph->daddr));
This hash approach sounds reasonable, but I feel a bit uncomfortable
with the idea that the flowtable bypasses _entirely_ the existing
firewall policy and that this does not provide a perfect match. The
idea is that only initial packets of a flow goes through the policy,
then once flow is added in the flowtabled such firewall policy
validation is circumvented.
To achieve a perfect match, this means more memory consumption to
store the two IPs in the tuple.
struct {
u16 id;
__be16 proto;
} encap[NF_FLOW_TABLE_ENCAP_MAX];
And possibility more information will need to be stored for other
layer 3 tunnel protocols.
While this hash trick looks like an interesting approach, I am
ambivalent.
And one nitpick (typo) below...
> + ctx->dev = rt->dst.dev;
> + ip_rt_put(rt);
> +
> + return 0;
> +}
> +
[...]
> +static void nf_flow_ip4_ecanp_pop(struct sk_buff *skb)
_encap_pop ?
View attachment "ipip-tx.patch" of type "text/x-diff" (5866 bytes)
Powered by blists - more mailing lists