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: <CADsK2K9_MVnMp+_SQmjweUoX1Hpnyquc1nW+qh2DDVUqPpEw8w@mail.gmail.com>
Date: Tue, 3 Sep 2024 11:19:41 -0700
From: Feng Wang <wangfe@...gle.com>
To: Leon Romanovsky <leon@...nel.org>
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

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.

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?

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.

Thanks for your help.

Feng