netdev - Re: ip rule iif oif and vrf

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:   Wed, 23 Sep 2020 19:47:16 -0600
From:   David Ahern <dsahern@...il.com>
To:     Stephen Suryaputra <ssuryaextr@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: ip rule iif oif and vrf

On 9/23/20 5:50 PM, Stephen Suryaputra wrote:
> 
> I have a reproducer using namespaces attached in this email (gre_setup.sh).

Thanks for the script. Very helpful.

Interesting setup.


# +-------+     +----------+   +----------+   +-------+
# | h0    |     |    r0    |   |    r1    |   |    h1 |
# |    v00+-----+v00    v01+---+v10    v11+---+v11    |
# |       |     |          |   |          |   |       |
# +-------+     +----------+   +----------+   +-------+
#                  |    <===gre===>    |
#                  | gre01       gre10 |
#                  |                   |
#          vrf_r0t | vrf_r0c   vrf_r1c | vrf_r1t
#         (tenant)        (core)         (tenant)
# h0_v00 10.0.0.2/24     r0_v00 10.0.0.1/24
# r0_v01 1.1.1.1/24      r1_v10 1.1.1.2/24
# h1_v11 11.0.0.2/24     r1_v11 11.0.0.1/24
# gre01 2.2.2.1/30       gre10 2.2.2.2/30


You have route leaking for the jump from tenant to core and the gre
devices in the core VRF. For the jump from core to tenant, you are
trying to use fib rules based on gre device index.

Yea, that is not going to work since the skb->dev is set to the VRF
device and it is not a simple change to remove that swap.

If I remove the fib rules and add VRF route leaking from core to tenant
it works. Why is that not an option? Overlapping tenant addresses?

One thought to get around it is adding support for a new FIB rule type
-- say l3mdev_port. That rule can look at the real ingress device which
is saved in the skb->cb as IPCB(skb)->iif.