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: <e90396a3-774f-439c-9c98-8ea5c74e7606@6wind.com>
Date: Fri, 5 Apr 2024 15:29:59 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Antony Antony <antony@...nome.org>
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

Le 05/04/2024 à 14:29, Antony Antony a écrit :
> 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:)
Noted :)

With this check, everything is open for later ;-)


Thanks,
Nicolas