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

Message-ID: <ZhAIdoNsmwXSK59t@Antony2201.local>
Date: Fri, 5 Apr 2024 16:19:34 +0200
From: Antony Antony <antony@...nome.org>
To: Feng Wang <wangfe@...gle.com>
Cc: Leon Romanovsky <leon@...nel.org>,
	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

Hi Feng,

On Wed, Apr 03, 2024 at 09:45:07AM +0300, Leon Romanovsky wrote:
> On Tue, Apr 02, 2024 at 02:10:16PM -0700, Feng Wang wrote:
> > The xfrm interface ID is the index of the ipsec device, for example,
> > ipsec11, ipsec12.  One ipsec application(VPN) might create an ipsec11
> > interface and send the data through this interface.

Where to find xfrm interface if_id depends on the direction the packet is 
traversing, direction "out": (clear text in ESP out), or "in": (ESP in clear 
text out) use if_id diffrently.

Which case are you looking at? It sounds like out.

> > Another application(Wifi calling) might create an ipsec12 interface and
> > send its data through ipsec12.  Both packets are routed through the kernel
> > to the one device driver(wifi).  When the device driver receives the
> > packet, it needs to find the correct application parameters to encrypt the

this looks like an out case. After a successful dst lookup, xfrm_lookup(),

look at skb_dst(skb)->xfrm->if_id ?

> > packet.  So if the skb_iif is marked by the kernel with ipsec11 or
> > ipsec12,  device driver can use this information to find the corresponding
> > parameter.  I hope I explain my user case clearly.  If there is any
> > misunderstanding, please let me know.  I try my best to make it clear.

skb_dst(skb)->xfrm->if_id should match  what is in the xfrm policy I think,
p->if_id.

Note I assumed the packet is locally generated. If it is a forwarded packet 
there could be another policy lookup before.
 
> Like I said before, please send the code which uses this feature. Right
> now, packet offload doesn't need this feature.

+1
-antony