netdev - Re: [PATCH 1/2] 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] [day] [month] [year] [list]

Message-ID: <CADsK2K_D8EZCm2_BtJ878z=a-mp2q=dUtwgfT50ZgcPafrs3XQ@mail.gmail.com>
Date: Thu, 7 Nov 2024 16:32:13 -0800
From: Feng Wang <wangfe@...gle.com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Antony Antony <antony.antony@...unet.com>, netdev@...r.kernel.org, 
	steffen.klassert@...unet.com
Subject: Re: [PATCH 1/2] xfrm: add SA information to the offloaded packet

Based on current kernel implementation,  the packet offload does match
policy and state on the TX side in the kernel.  For the RX side, the
driver is responsible for the selector policy and SA match etc.
I added some logs in the kernel, and listed the kernel function call
flow as below for your reference, this is for TX side only.

 (1) ip_output -> neighbor_output -> dev_queue_xmit ->
netdev_start_xmit -> ops->ndo_start_xmit -> xfrmi_xmit -> xfrmi_xmit2
 (2) In the xfrmi_xmit2  {  first call xfrm_lookup_with_ifid() to get
next destination(dst),  then call dst_output() to send the packet,
the dst_output in fact is xfrm_output() }
 (3) To trace xfrm_lookup_with_ifid()   xfrm_lookup_with_ifid() ->
xfrm_bundle_lookup() ->
        {      first call xfrm_policy_lookup() to find the policy, the
policy id is checked here.
                Then call xfrm_resolve_and_create_bundle() to find the
SA and generate the next dst
                return dst;
        }
(4)To trace xfrm_output(),  now we know the next dst, calls
xfrm_output to send the packet.  xfrm_output() -> xfrm_output_resume()
 ->
        {
              first call xfrm_output_one() which goes to resume part
directly without packet transformation(this is special handling for
packet offload) but it calls skb_dst_pop to get final dst. This dst
has no xfrm(SA) so the driver can't access xfrm(SA) using skb_dst.
              Then calls dst_output() with final dst, this will route
the packet to stack again, going through ip_output() etc to pass the
packet to the driver transmit function, and send out.
         }

I did make a mistake on calling xfrm_sk_policy_lookup in the
xfrm_lookup_with_ifid function.  In fact,  it is NOT called.

Thanks,
Feng