netdev - Re: VRF + ip xfrm, egress ESP packet looping when qdisc configured

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]

Date:   Sun, 2 Feb 2020 22:13:30 -0500
From:   Trev Larock <trev@...ock.ca>
To:     David Ahern <dsahern@...il.com>
Cc:     Ben Greear <greearb@...delatech.com>, netdev@...r.kernel.org
Subject: Re: VRF + ip xfrm, egress ESP packet looping when qdisc configured

On Mon, Jan 13, 2020 at 11:51 AM David Ahern <dsahern@...il.com> wrote:
> Trev's problem is looping due to the presence of the qdisc. The vrf
> driver needs to detect that it has seen the packet and not redirect it
> again.
Yes note it was when specifying no dev on the xfrm policy/state.
For the non-qdisc case the policy triggered from the __ip4_datagram_connect->
xfrm_lookup and the vrf "direct" route sent it out without any xfrm_lookup call.
It appears to work but it's not really a "xfrm vrf specific " policy.

For qdisc the policy matched again on the vrf->xfrm_lookup call.

When specifying "dev vrf0" I don't see the policy get matched at all.
Should that be triggered in the vrf.c -> xfrm_lookup  call from
vrf_process_v4_outbound or elsewhere?

(The qdisc case seems more like the older / pre dcdd43c41e commit flow.)

>From ftrace stack trace with qdisc and sending UDP packet with netcat
   nc-4391  [001] .... 11663.551103: xfrm_lookup <-xfrm_lookup_route
   nc-4391  [001] .... 11663.551104: <stack trace>
 => xfrm_lookup
 => xfrm_lookup_route
 => vrf_xmit
 => dev_hard_start_xmit
 => sch_direct_xmit
 => __qdisc_run
 => __dev_queue_xmit
 => vrf_finish_output
 => vrf_output
 => ip_send_skb
 => udp_send_skb
 => udp_sendmsg
 => sock_sendmsg
 => SYSC_sendto
 => do_syscall_64
 => entry_SYSCALL_64_after_hwframe

Full flow from vrf_xmit:
vrf_xmit
 -->is_ip_tx_frame
   -->vrf_process_v4_outbound
     -->ip_route_output_flow
       -->xfrm_lookup_route
         --> xfrm_lookup

In vrf_process_v4_outbound the flow sets ".flowi4_oif = vrf_dev->ifindex",
should that match the vrf ifindex or the network interface enslaved to the vrf?
I observe it's = network interface so matching a policy with dev vrf0
won't trigger, but not sure if it's missing config or some other issue.
Is there any reference/test sample configs for vrf+xfrm use case where
that matched policy as expected? (even on older kernel).

Thanks,
Trev