netdev - Re: [PATCH ipsec-next 2/5] xfrm: simplify SA initialization routine

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: <Z68M/4jka5FwrvLV@gauss3.secunet.de>
Date: Fri, 14 Feb 2025 10:29:35 +0100
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Leon Romanovsky <leon@...nel.org>
CC: Andrew Lunn <andrew+netdev@...n.ch>, Ayush Sawal
	<ayush.sawal@...lsio.com>, Bharat Bhushan <bbhushan2@...vell.com>, "Eric
 Dumazet" <edumazet@...gle.com>, Geetha sowjanya <gakula@...vell.com>,
	hariprasad <hkelam@...vell.com>, Herbert Xu <herbert@...dor.apana.org.au>,
	<intel-wired-lan@...ts.osuosl.org>, Jakub Kicinski <kuba@...nel.org>, "Jay
 Vosburgh" <jv@...sburgh.net>, Jonathan Corbet <corbet@....net>,
	<linux-doc@...r.kernel.org>, <linux-rdma@...r.kernel.org>, Louis Peens
	<louis.peens@...igine.com>, <netdev@...r.kernel.org>,
	<oss-drivers@...igine.com>, Paolo Abeni <pabeni@...hat.com>, "Potnuri Bharat
 Teja" <bharat@...lsio.com>, Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Saeed Mahameed <saeedm@...dia.com>, Subbaraya Sundeep <sbhatta@...vell.com>,
	Sunil Goutham <sgoutham@...vell.com>, Tariq Toukan <tariqt@...dia.com>, "Tony
 Nguyen" <anthony.l.nguyen@...el.com>, Ilia Lin <ilia.lin@...nel.org>
Subject: Re: [PATCH ipsec-next 2/5] xfrm: simplify SA initialization routine

On Wed, Feb 12, 2025 at 08:30:20PM +0200, Leon Romanovsky wrote:
> On Wed, Feb 12, 2025 at 12:56:48PM +0100, Steffen Klassert wrote:
> > On Wed, Feb 05, 2025 at 08:20:21PM +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky <leonro@...dia.com>
> > > 
> > > SA replay mode is initialized differently for user-space and
> > > kernel-space users, but the call to xfrm_init_replay() existed in
> > > common path with boolean protection. That caused to situation where
> > > we have two different function orders.
> > > 
> > > So let's rewrite the SA initialization flow to have same order for
> > > both in-kernel and user-space callers.
> > > 
> > > Signed-off-by: Leon Romanovsky <leonro@...dia.com>
> > > ---
> > >  include/net/xfrm.h    |  3 +--
> > >  net/xfrm/xfrm_state.c | 22 ++++++++++------------
> > >  net/xfrm/xfrm_user.c  |  2 +-
> > >  3 files changed, 12 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/include/net/xfrm.h b/include/net/xfrm.h
> > > index 28355a5be5b9..58f8f7661ec4 100644
> > > --- a/include/net/xfrm.h
> > > +++ b/include/net/xfrm.h
> > > @@ -1770,8 +1770,7 @@ void xfrm_spd_getinfo(struct net *net, struct xfrmk_spdinfo *si);
> > >  u32 xfrm_replay_seqhi(struct xfrm_state *x, __be32 net_seq);
> > >  int xfrm_init_replay(struct xfrm_state *x, struct netlink_ext_ack *extack);
> > >  u32 xfrm_state_mtu(struct xfrm_state *x, int mtu);
> > > -int __xfrm_init_state(struct xfrm_state *x, bool init_replay,
> > > -		      struct netlink_ext_ack *extack);
> > > +int __xfrm_init_state(struct xfrm_state *x, struct netlink_ext_ack *extack);
> > >  int xfrm_init_state(struct xfrm_state *x);
> > >  int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type);
> > >  int xfrm_input_resume(struct sk_buff *skb, int nexthdr);
> > > diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
> > > index 568fe8df7741..42799b0946a3 100644
> > > --- a/net/xfrm/xfrm_state.c
> > > +++ b/net/xfrm/xfrm_state.c
> > > @@ -3120,8 +3120,7 @@ u32 xfrm_state_mtu(struct xfrm_state *x, int mtu)
> > >  }
> > >  EXPORT_SYMBOL_GPL(xfrm_state_mtu);
> > >  
> > > -int __xfrm_init_state(struct xfrm_state *x, bool init_replay,
> > > -		      struct netlink_ext_ack *extack)
> > > +int __xfrm_init_state(struct xfrm_state *x, struct netlink_ext_ack *extack)
> > 
> > The whole point of having __xfrm_init_state was to
> > sepatate codepaths that need init_replay and those
> > who don't need it. That was a bandaid for something,
> > unfortunately I don't remenber for what.
> > 
> > If we don't need that anymore, maybe we can merge
> > __xfrm_init_state into xfrm_init_state, as it was
> > before.
> 
> Main difference between __xfrm_init_state and xfrm_init_state is that
> latter is called without extack, which doesn't exist in kernel path.

That split happened ~ 15 years ago, we did not have extack back than.
But I'm also ok with keeping it if extack is a reason for it.

Do you plan to respin, or should I take the patchset as is?

Thanks!