netdev - Re: [devel-ipsec] [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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZiYq729Q1AF2Xq8M@hog>
Date: Mon, 22 Apr 2024 11:16:31 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Antony Antony <antony@...nome.org>
Cc: 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: [devel-ipsec] [PATCH ipsec-next v10 1/3] xfrm: Add Direction to
 the SA in or out

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?

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.


> > > And also this looks like a general cleanup up to me. I wonder how Steffen 
> > > would add such a check for the upcoming PCPU attribute! Should that be 
> > > prohibited DELSA or XFRM_MSG_FLUSHSA or DELSA?
> > 
> > IMO, new attributes should be rejected in any handler that doesn't use
> > them. That's not a general cleanup because it's a new attribute, and
> > the goal is to allow us to decide later if we want to use that
> > attribute in DELSA etc. Maybe in one year, we want to make DELSA able
> > to match on SA_DIR. If we don't reject SA_DIR from DELSA now, we won't
> > be able to do that. That's why I'm insisting on this.
> 
> I have implemented a method to reject in v11, even though it is not my 
> preference:) My argument xfrm has no precedence of limiting unused 
> attributes in most types. We are not enforcing on all attributes such as 
> upcoming PCPU.

I'll ask Steffen to enforce it there as well :)
I think it's a mistake that old netlink APIs were too friendly to invalid input.

-- 
Sabrina