[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Ziesv_sLWXqnZVoO@Antony2201.local>
Date: Tue, 23 Apr 2024 14:42:39 +0200
From: Antony Antony <antony@...nome.org>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: Antony Antony <antony@...nome.org>,
Antony Antony <antony.antony@...unet.com>,
Steffen Klassert <steffen.klassert@...unet.com>,
Herbert Xu <herbert@...dor.apana.org.au>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
devel@...ux-ipsec.org, Leon Romanovsky <leon@...nel.org>,
Eyal Birger <eyal.birger@...il.com>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>
Subject: Re: [PATCH ipsec-next v10 1/3] xfrm: Add Direction to the SA in or
out
Hi Sabrina,
On Mon, Apr 22, 2024 at 11:16:31AM +0200, Sabrina Dubroca via Devel wrote:
> 2024-04-22, 00:04:55 +0200, Antony Antony wrote:
> > Hi Sabrina,
> >
> > On Tue, Apr 16, 2024 at 10:36:16AM +0200, Sabrina Dubroca wrote:
> > > 2024-04-16, 09:10:25 +0200, Antony Antony wrote:
> > > > On Mon, Apr 15, 2024 at 02:21:50PM +0200, Sabrina Dubroca via Devel wrote:
> > > > > 2024-04-11, 11:40:59 +0200, Antony Antony wrote:
> > > > > > diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
> > > > > > index 6346690d5c69..2455a76a1cff 100644
> > > > > > --- a/net/xfrm/xfrm_device.c
> > > > > > +++ b/net/xfrm/xfrm_device.c
> > > > > > @@ -253,6 +253,12 @@ int xfrm_dev_state_add(struct net *net, struct xfrm_state *x,
> > > > > > return -EINVAL;
> > > > > > }
> > > > > >
> > > > > > + if ((xuo->flags & XFRM_OFFLOAD_INBOUND && x->dir == XFRM_SA_DIR_OUT) ||
> > > > > > + (!(xuo->flags & XFRM_OFFLOAD_INBOUND) && x->dir == XFRM_SA_DIR_IN)) {
> > > > > > + NL_SET_ERR_MSG(extack, "Mismatched SA and offload direction");
> > > > > > + return -EINVAL;
> > > > > > + }
> > > > >
> > > > > It would be nice to set x->dir to match the flag, but then I guess the
> > > > > validation in xfrm_state_update would fail if userspaces tries an
> > > > > update without providing XFRMA_SA_DIR. (or not because we already went
> > > > > through this code by the time we get to xfrm_state_update?)
> > > >
> > > > this code already executed from xfrm_state_construct.
> > > > We could set the in flag in xuo when x->dir == XFRM_SA_DIR_IN, let me think
> > > > again. May be we can do that later:)
> > >
> > > I mean setting x->dir, not setting xuo, ie adding something like this
> > > to xfrm_dev_state_add:
> > >
> > > x->dir = xuo->flags & XFRM_OFFLOAD_INBOUND ? XFRM_SA_DIR_IN : XFRM_SA_DIR_OUT;
> > >
> > > xuo will already be set correctly when we're using offload, and won't
> > > be present if we're not.
> >
> > Updating with older tools may fail validation. For instance, if a user creates
> > an SA using an older iproute2 with offload and XFRM_OFFLOAD_INBOUND flag
> > set, the kernel sets x->dir = XFRM_SA_DIR_IN. Then, if the user wants to
> > update this SA using the same older iproute2, which doesn't allow setting
> > dir, the update will fail.
>
> I'm not sure it would, since as you said xfrm_state_construct would
> have set x->dir based on XFRM_OFFLOAD_INBOUND. But if that's the case,
> then that can be added later, because it would not change any behavior.
>
> > However, as I proposed, if SA dir "in" and offload is enabled, the kernel
> > could set xuo->flags &= XFRM_OFFLOAD_INBOUND to avoid double typing.
>
> Do you mean in iproute?
I was thinking kernel. Then the API would be simple iproute2 or *swans.
ip xfrm state .... dir in offload dev mlx0 dir in
notice "dir in" twice. this can be tweaked later:) However, this would
work only with newer kernels.
>
> On the kernel side, xuo has to be provided when offloading, and the
> meaning of (xuo->flags & XFRM_OFFLOAD_INBOUND) is well defined (0 =
> out, !0 = in). xuo->flags & XFRM_OFFLOAD_INBOUND == 0 with SA_DIR ==
> IN must remain an invalid config.
yes I agree.
Powered by blists - more mailing lists