netdev - Re: [PATCH] ip link: Prevent duplication of table id for vrf tables

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] [day] [month] [year] [list]

Message-ID: <1b4d5428-75f8-debb-983d-3ec4d63f8257@gmail.com>
Date:   Tue, 10 Mar 2020 17:33:38 -0600
From:   David Ahern <dsahern@...il.com>
To:     Donald Sharp <sharpd@...ulusnetworks.com>
Cc:     netdev@...r.kernel.org, dsahern@...nel.org,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Stephen Worley <sworley@...ulusnetworks.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [PATCH] ip link: Prevent duplication of table id for vrf tables

On 3/9/20 6:16 AM, Donald Sharp wrote:
> David -
> 
> I'm more than a bit confused about this stance.  I've been repeatedly
> told by the likes of you, Roopa, and Nikolay that we cannot modify the
> kernel behavior.  I get that, so that leaves me with user space
> responses.  I went this route because not allowing the end user to
> make this mistake would have saved us a stupid amount of time from
> having to debug/understand/rectify ( rinse repeat for every incident
> ).  A warning wouldn't have saved us here since this was all automated
> and a warning won't generate any actionable return codes from using
> `ip link add...`.  If the argument is that other people are doing it
> wrong too, point me at them and I'll submit patches there too.  In
> other words a user management problem that the kernel/iproute2 hog
> ties me from being actually able to stop mistakes when they happen is
> an interesting response.
> 
> Part of this is that the routing stack considers vrf completely
> independent and we don't have duplicate labels to identify the same
> table( nor can I think of a good use case where this would be even
> advisable and if you can please let me know as that I want to
> understand this ).  We have a set of actions we perform when we
> receive routing data from the kernel and if we don't act on the right
> vrf we've broken routing.  This routing data sent over the netlink bus
> is the tableid, if we can't stop users from making mistakes, can we
> modify the netlink code actually send us disambiguous data then and
> include the label as well as part of the route update?

As you know multiple tables existed long before VRF devices. The VRF
device provides the programmatic API for an end-to-end solution. To name
a few:
- moving packets (ingress via device A which is in VRF B to look up in
table C),
- applications (bind this socket to VRF B, a name for the table id), and
- assorted notifications like device enslave / removal.

I did think about the multiple devices pointing to the same table during
development, and at that time I did not see a reason to prevent it.
Ultimately, the kernel does not care which is why I say it is a
userspace problem.

Yes, people make mistakes and tests will typically use ip for scripting.
Existing behavior allows it, and we can't break that. Given where we are
any change needs to be opt in.

For example, your patch can generate a 'WARNING: you are doing something
unexpected or wrong' message. From there what comes to mind is the
compiler option Werror - make warnings fatal. e.g., for iproute2, it
could a new top-level option  (ip -Werror) so that you can alias it
(alias ip='ip -Werror') and then iproute2 has a warning function to
display warnings to the user that when Werror is passed that function
does exit(1) to cause the command to fail.