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

Message-ID: <20250212183020.GJ17863@unreal>
Date: Wed, 12 Feb 2025 20:30:20 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Steffen Klassert <steffen.klassert@...unet.com>
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 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.

E.g  xfrm_init_state(struct xfrm_state *x) vs. __xfrm_init_state(struct xfrm_state *x, struct netlink_ext_ack *extack).
So if we merge them, we will need to change all xfrm_init_state()
callers to provide extack == NULL.

IMHO, such churn of changing xfrm_init_state() callers is not worth it for now.

Thanks

> 
> The rest of the patchset looks OK to me.