netdev - Re: [PATCH] ipv4: fix ipsec forward performance regression

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1110231533410.1499@ja.ssi.bg>
Date:	Sun, 23 Oct 2011 17:52:46 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	"Yan, Zheng" <zheng.z.yan@...el.com>
cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
	Kim Phillips <kim.phillips@...escale.com>
Subject: Re: [PATCH] ipv4: fix ipsec forward performance regression


	Hello,

On Sun, 23 Oct 2011, Yan, Zheng wrote:

> There is bug in commit 5e2b61f(ipv4: Remove flowi from struct rtable).
> It makes xfrm4_fill_dst() modify wrong data structure.
> 
> Signed-off-by: Zheng Yan <zheng.z.yan@...el.com>
> ---
>  net/ipv4/xfrm4_policy.c |   14 +++++++-------
>  1 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
> index fc5368a..a0b4c5d 100644
> --- a/net/ipv4/xfrm4_policy.c
> +++ b/net/ipv4/xfrm4_policy.c
> @@ -79,13 +79,13 @@ static int xfrm4_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,
>  	struct rtable *rt = (struct rtable *)xdst->route;
>  	const struct flowi4 *fl4 = &fl->u.ip4;
>  
> -	rt->rt_key_dst = fl4->daddr;
> -	rt->rt_key_src = fl4->saddr;
> -	rt->rt_key_tos = fl4->flowi4_tos;
> -	rt->rt_route_iif = fl4->flowi4_iif;
> -	rt->rt_iif = fl4->flowi4_iif;
> -	rt->rt_oif = fl4->flowi4_oif;
> -	rt->rt_mark = fl4->flowi4_mark;
> +	xdst->u.rt.rt_key_dst = fl4->daddr;
> +	xdst->u.rt.rt_key_src = fl4->saddr;
> +	xdst->u.rt.rt_key_tos = fl4->flowi4_tos;
> +	xdst->u.rt.rt_route_iif = fl4->flowi4_iif;

	May be I'm missing something but I don't see where
flowi4_iif is set for the forwarding case. __xfrm_route_forward
calls xfrm_decode_session which does not appear to set
flowi4_iif. When providing fl4 for output routes flowi4_iif
is always set to 0, so it represents rt_route_iif. But
then there are 2 variants for __ip_route_output_key:

- ip_route_output_slow sets flowi4_iif to loopback and
flowi4_oif to outdev during lookup but never restores them
to original values. It is assumed that caller uses outdev
from dst, not from flowi4_oif.

- for cached route we do not update flowi4_iif and flowi4_oif
in __ip_route_output_key, so the resulting fl4 can not be
used for these values. I assume, the current rules are that
only fl4.saddr and daddr are updated while flowi4_iif and
flowi4_oif are not. It looks wrong flowi code to rely on them.

	Currently, we have 3 values for devices:

rt_iif: indev for input routes, resulting outdev for output routes
which plays the role as indev for loopback traffic.

rt_oif: original outdev key, 0 for input routes, can be 0 for
output routes if socket is not bound to oif

rt_route_iif: indev for input routes, 0 for output routes

	With above rules for flowi4_iif and flowi4_oif
it is impossible to select value for rt_iif from fl4.

	I don't know the xfrm code well, may be after the
mentioned change we damaged rt_oif and rt_route_iif values
for cached dst which can lead to using slow path all the time.
Even if rt_intern_hash() avoids caching similar dsts multiple
times, if cached entry is damaged we will add more and
more new entries after every damage.

> +	xdst->u.rt.rt_iif = fl4->flowi4_iif;
> +	xdst->u.rt.rt_oif = fl4->flowi4_oif;
> +	xdst->u.rt.rt_mark = fl4->flowi4_mark;
>  
>  	xdst->u.dst.dev = dev;
>  	dev_hold(dev);

Regards

--
Julian Anastasov <ja@....bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html