netdev - Re: [RFC PATCH] Don't copy mark from encapsulated packet when routing VXLAN

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 1 Oct 2019 08:30:08 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Jethro Beekman <jethro@...tanix.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Petr Machata <petrm@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        Stefano Brivio <sbrivio@...hat.com>,
        Litao jiao <jiaolitao@...secom.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] Don't copy mark from encapsulated packet when routing VXLAN

On Sun, Sep 29, 2019 at 11:27 PM Jethro Beekman <jethro@...tanix.com> wrote:
>
> When using rule-based routing to send traffic via VXLAN, a routing
> loop may occur. Say you have the following routing setup:
>
> ip rule add from all fwmark 0x2/0x2 lookup 2
> ip route add table 2 default via 10.244.2.0 dev vxlan1 onlink
>
> The intention is to route packets with mark 2 through VXLAN, and
> this works fine. However, the current vxlan code copies the mark
> to the encapsulated packet. Immediately after egress on the VXLAN
> interface, the encapsulated packet is routed, with no opportunity
> to mangle the encapsulated packet. The mark is copied from the
> inner packet to the outer packet, and the same routing rule and
> table shown above will apply, resulting in ELOOP.
>
> This patch simply doesn't copy the mark from the encapsulated packet.
> I don't intend this code to land as is, but I want to start a
> discussion on how to make separate routing of VXLAN inner and
> encapsulated traffic easier.

yeah, i think the patch as is will break users who use mark to
influence the underlay route lookup.
When you say the mark is copied into the packet, what exactly are you
seeing and where is the copy happening ?



>
> Signed-off-by: Jethro Beekman <jethro@...tanix.com>
> ---
>  drivers/net/vxlan.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 3d9bcc9..f9ed1b7 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -2236,7 +2236,6 @@ static struct rtable *vxlan_get_route(struct vxlan_dev *vxlan, struct net_device
>         memset(&fl4, 0, sizeof(fl4));
>         fl4.flowi4_oif = oif;
>         fl4.flowi4_tos = RT_TOS(tos);
> -       fl4.flowi4_mark = skb->mark;
>         fl4.flowi4_proto = IPPROTO_UDP;
>         fl4.daddr = daddr;
>         fl4.saddr = *saddr;
> @@ -2294,7 +2293,6 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan,
>         fl6.daddr = *daddr;
>         fl6.saddr = *saddr;
>         fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tos), label);
> -       fl6.flowi6_mark = skb->mark;
>         fl6.flowi6_proto = IPPROTO_UDP;
>         fl6.fl6_dport = dport;
>         fl6.fl6_sport = sport;
> --
> 2.7.4
>
>