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: <Z6yMgPSfPzgGHTkD@gauss3.secunet.de>
Date: Wed, 12 Feb 2025 12:56:48 +0100
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Leon Romanovsky <leon@...nel.org>
CC: Leon Romanovsky <leonro@...dia.com>, 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 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.

The rest of the patchset looks OK to me.