netdev - Re: [PATCH] xfrm: add SA information to the offloaded packet

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: <20240831173616.GB4000@unreal>
Date: Sat, 31 Aug 2024 20:36:16 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Feng Wang <wangfe@...gle.com>
Cc: Steffen Klassert <steffen.klassert@...unet.com>, netdev@...r.kernel.org,
	antony.antony@...unet.com
Subject: Re: [PATCH] xfrm: add SA information to the offloaded packet

On Fri, Aug 30, 2024 at 05:27:29PM -0700, Feng Wang wrote:
> Hi Leon,
> 
> I believe you are right about the mlx5e_ipsec_feature_check function.
> And it shows that the driver can indeed make use of the SA
> information. Similarly, in packet offload mode, drivers can
> potentially leverage this information for their own purposes. The
> patch is designed to be non-intrusive, so drivers that don't utilize
> this information won't be affected in any way.

I asked about examples of such drivers. Can you please provide them?

> 
> I'm also curious about why the mlx driver doesn't seem to use the XFRM
> interface ID in the same way that xfrm_policy_match() does.
> https://elixir.bootlin.com/linux/v6.10.7/source/net/xfrm/xfrm_policy.c#L1993a

HW offload is always last in packet TX traversal and it means that if HW
catches that packet and it meets the HW offload requirements, it will be
encrypted. The main idea is that routing (sending to right if_id) is handled
by the upper layers and HW offload is just a final step.

> This ID is critical in scenarios with multiple IPsec tunnels, where
> source and destination addresses alone might not be sufficient to
> identify the correct security policy. Perhaps there's a specific
> reason or design choice behind this in the mlx driver?

It is not specific to mlx5, but to all HW offload drivers. They should
implement both policy and SA offloading. It is violation of current mailing
list deign to do not offload policy. If you offload both policy and SA, you
won't need if_id at all.

> 
> Thank you once again for your valuable insights and collaboration.
> 
> Feng