linux-kernel - Re: [PATCH net] net: vlan: allow vlan device MTU change follow real device from smaller to bigger

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: <20220223194624.GD19531@debian.home>
Date:   Wed, 23 Feb 2022 20:46:24 +0100
From:   Guillaume Nault <gnault@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Eric Dumazet <edumazet@...gle.com>,
        "Ziyang Xuan (William)" <william.xuanziyang@...wei.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Vasily Averin <vvs@...tuozzo.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] net: vlan: allow vlan device MTU change follow real
 device from smaller to bigger

On Wed, Feb 23, 2022 at 09:37:49AM -0800, Jakub Kicinski wrote:
> On Wed, 23 Feb 2022 17:58:36 +0100 Guillaume Nault wrote:
> > On Wed, Feb 23, 2022 at 08:03:42AM -0800, Jakub Kicinski wrote:
> > > I meant
> > > 
> > >   ip link set dev vlan0 mtu-policy blah
> > > 
> > > but also
> > > 
> > >   ip link set dev bond0 mtu-policy blah
> > > 
> > > and
> > > 
> > >   ip link set dev macsec0 mtu-policy blah2
> > >   ip link set dev vxlan0 mtu-policy blah2
> > > 
> > > etc.  
> > 
> > Unless I'm missing something, that looks very much like what I proposed
> > (these are all ARPHRD_ETHER devices). It's just a bit unclear whether
> > "ip link set dev vlan0 mtu-policy blah" applies to vlan0 or to the vlans
> > that might be stacked on top of it (given your other examples, I assume
> > it's the later).
> 
> No, sorry I thought it would be clear, we need that neuralink ;)
> It applies to the device on which it's configured. What I mean
> is that bond, macsec, mpls etc have the same "should it follow 
> the MTU of the lower device" problem, it's not vlan specific.
> Or am I wrong about that?

Ok, I get it now, sorry for being slow :). But I wouldn't consider mpls
and vxlan. We have no device type for mpls. For vxlan (and other ip
tunnels) the virtual device isn't directly tied to a physical device.
Also, ip tunnels can resort to fragmentation in case of small MTU on
the output device, so following MTU changes is not a hard requirement
as with vlans.

For other devices, we'd probably have to take into account the fact
that some of them need to have a smaller MTU due to their extra header
(that can be the case for some stacked vlans scenarios).

But honnestly, I don't believe it's worth the extra complexity.

> > > To be honest I'm still not clear if this is a real problem.
> > > The patch does not specify what the use case is.  
> > 
> > It's probably not a problem as long as we keep sane behaviour by
> > default. Then we can let admins opt in for something more complex or
> > loosely defined.
> 
> What I meant was - does anyone actually flip the MTU of their
> interfaces back and forth while the system is running. Maybe
> people do.

In my experience people often try to upgrade their MTU, which is prone
to failure because all nodes on the ethernet segment need to be
upgraded at once (and people like unmanageably big ethernet segments).
So reverting to the previous configuration is often needed.
Another reason for back and forth modifications is fat fingers: change
the MTU of a device, realise that was the wrong one, restore settings
and reapply on the correct device.

More importantly, one path people take to upgrade their MTU is to
ensure that all their traffic is vlan encapsulated, then higher the MTU
of the ethernet device, and finally higher the MTU of each vlan on a
case by case basis. In such scenarios, you certainly _don't_ want the
vlans to follow the MTU of their parent device, no matter if their MTU
is the default one, if it's equal to the current MTU of the eth
interface, if it was ever modified since the creation of the device,
or any other situation heuristics might use.