netdev - Re: [PATCH] [PATCH ipsec] xfrm: Store ipsec interface index

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>] [day] [month] [year] [list]

Message-ID: <20240402075104.GD11187@unreal>
Date: Tue, 2 Apr 2024 10:51:04 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Feng Wang <wangfe@...gle.com>
Cc: Steffen Klassert <steffen.klassert@...unet.com>, netdev@...r.kernel.org,
	herbert@...dor.apana.org.au, davem@...emloft.net
Subject: Re: [PATCH] [PATCH ipsec] xfrm: Store ipsec interface index

On Mon, Apr 01, 2024 at 11:09:41AM -0700, Feng Wang wrote:
> Thanks Leon for answering my question.  In the above example, if we can
> pass the xfrm interface id to the HW, then HW can distinguish them based on
> it. That's what my patch is trying to do.

>From partial grep, it looks like "xfrm interface id" is actually netdevice
index. If this is the case, HW doesn't need to know about it, because
packet offload is performed by specific device and skb_iif will be equal
to that index anyway.

> Would you please take this into consideration? If needed, I can improve my
> patch.

As a standalone patch, it is not correct. If you have a real use case,
please send together with code which uses it.

Thanks

> 
> Thanks,
> 
> Feng
> 
> 
> 
> 
> On Mon, Apr 1, 2024 at 7:27 AM Leon Romanovsky <leon@...nel.org> wrote:
> 
> > On Fri, Mar 22, 2024 at 12:14:44PM -0700, Feng Wang wrote:
> > > Hi Leon and Steffen,
> > >
> > > Thanks for providing me with the information. I went through the offload
> > > driver code but I didn't find any solution for my case.  Is there any
> > > existing solution available?  For example, there are 2 IPSec sessions
> > with
> > > the same xfrm_selector results, when trying to encrypt the packet, how to
> > > find out which session this packet belongs to?
> >
> > HW catches packets based on match criteria of source and destination. If
> > source, destination and other match criteria are the same for different
> > sessions, then from HW perspective, it is the same session.
> >
> > Thanks
> >