netdev - Re: [PATCH ipsec-next v10 1/3] xfrm: Add Direction to the SA in or out

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] [day] [month] [year] [list]

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.