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: <20240903190418.GK4026@unreal>
Date: Tue, 3 Sep 2024 22:04:18 +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 Tue, Sep 03, 2024 at 11:19:41AM -0700, Feng Wang wrote:
> This patch simply assigns a value to a field, replicating existing
> crypto offload behavior - it's working/tested in that mode. Many
> instances within the kernel code utilize this information in different
> cases, making the implementation pretty simple and safe.

Not really, the thing that you are adding secpath in the place which
wasn't designed to have it, is very problematic. Crypto and packet
offloads are two different things as they treat packets differently.
First one sees them as ESP packets, while the second one sees them as
plain text packets.

> 
> Hi Leon,
> 
> "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."
> 
> Could you please clarify why the if_id is unnecessary in scenarios
> with hardware offload?

I have no objections to support xfrm IDs in the packet offload, my
request is to have upstream driver which uses this feature.

> 
> For instance, imagine I have two tunnel sessions sharing the same
> source and destination addresses. One tunnel utilizes xfrm ID 1, while
> the other uses xfrm ID 2. If a packet is sent out via xfrm ID 1 and
> lacks any specific markings, how does the hardware offload determine
> that this packet belongs to xfrm ID 1 and not xfrm ID 2? This
> distinction is crucial for the hardware to locate the correct
> encryption information and encrypt the packet accordingly.

HW doesn't know about xfrm ID, as this information is kernel specific.
In order HW will use this information someone needs to pass it to HW,
while configuring SA/policy and nothing in the kernel does that.

Thanks

> 
> Thanks for your help.
> 
> Feng