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: <20241107115031.GK5006@unreal>
Date: Thu, 7 Nov 2024 13:50:31 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Antony Antony <antony.antony@...unet.com>
Cc: Feng Wang <wangfe@...gle.com>, netdev@...r.kernel.org,
	steffen.klassert@...unet.com
Subject: Re: [PATCH 1/2] xfrm: add SA information to the offloaded packet

On Thu, Nov 07, 2024 at 09:52:09AM +0100, Antony Antony wrote:
> On Wed, Nov 06, 2024 at 16:14:36 -0800, Feng Wang wrote:
> > Antony brought out an important function xfrm_lookup_with_ifid(), this
> > function returns the next dst_entry.
> > 
> > The xfrm_lookup_with_ifid() function utilizes xfrm_sk_policy_lookup()
> 
> would the output packet, looked up using xfrm_lookup_with_ifid ,
> match xfrm policy with "offload packet" set?

According to my understanding, no.

> When lookup is in the xfrm device.
> 
> ip xfrm policy .... offload packet dev <if-name>
> 
> 
> > to find a matching policy based on the given if_id. The if_id checking
> > is handled in it.
> > Once the policy is found, xfrm_resolve_and_create_bundle() determines
> > the correct Security Association (SA) and associates it with the
> > destination entry (dst->xfrm).
> 
> If the output packet got this far, dst is set in skb?
> And when the packet reach the driver dst = skb_dst(skb);
> dst->xfrm is the state?
> If this is the case  why add state to skb as your patch proose?
> May be I am missing something in the packet path.
> 
> > This SA information is then passed directly to the driver. Since the
> > kernel has already performed the necessary if_id checks for policy,
> > there's no need for the driver to duplicate this effort.
> 
> Is this how packet offload would work? My guess was in packet offload
> policy look happens in the driver.

You are right, this is not how packet offload works.
The expectation is that HW sees and catches same selectors as SW.
It ensures that if SW finds policy/SA, HW will find the same.

Thanks

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ