netdev - Re: [PATCH ipsec-next v5] 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: <Zg_ukNvNpr6ANyvw@Antony2201.local>
Date: Fri, 5 Apr 2024 14:29:04 +0200
From: Antony Antony <antony@...nome.org>
To: nicolas.dichtel@...nd.com
Cc: antony.antony@...unet.com, Herbert Xu <herbert@...dor.apana.org.au>,
	devel@...ux-ipsec.org, netdev@...r.kernel.org,
	Eyal Birger <eyal.birger@...il.com>,
	Leon Romanovsky <leon@...nel.org>,
	Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [PATCH ipsec-next v5] xfrm: Add Direction to the SA in or out

On Thu, Apr 04, 2024 at 04:08:42PM +0200, Nicolas Dichtel via Devel wrote:
> Le 04/04/2024 à 10:32, Antony Antony a écrit :
> > This patch introduces the 'dir' attribute, 'in' or 'out', to the
> > xfrm_state, SA, enhancing usability by delineating the scope of values
> > based on direction. An input SA will now exclusively encompass values
> > pertinent to input, effectively segregating them from output-related
> > values. This change aims to streamline the configuration process and
> > improve the overall clarity of SA attributes.
> > 
> > This feature sets the groundwork for future patches, including
> > the upcoming IP-TFS patch. Additionally, the 'dir' attribute can
> > serve purely informational purposes.
> > It currently validates the XFRM_OFFLOAD_INBOUND flag for hardware
> > offload capabilities.
> Frankly, it's a poor API. It will be more confusing than useful.
> This informational attribute could be wrong, there is no check.
> Please consider use cases of people that don't do offload.
> 
> The kernel could accept this attribute only in case of offload. This could be
> relaxed later if needed. With no check at all, nothing could be done later, once
> it's in the uapi.

It is a minor change. I will send a v6 with this check, and express my 
preference for v5:)

Thanks for your feedback.

-antony