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

Date:   Tue, 22 Feb 2022 15:31:45 +0800
From:   "Ziyang Xuan (William)" <william.xuanziyang@...wei.com>
To:     Eric Dumazet <edumazet@...gle.com>
CC:     Herbert Xu <herbert@...dor.apana.org.au>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>,
        Vasily Averin <vvs@...tuozzo.com>,
        Kees Cook <keescook@...omium.org>,
        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 Mon, Feb 21, 2022 at 6:06 PM Ziyang Xuan (William)
> <william.xuanziyang@...wei.com> wrote:
>>
>>> On Mon, Feb 21, 2022 at 07:43:18AM -0800, Eric Dumazet wrote:
>>>>
>>>> Herbert, do you recall why only a decrease was taken into consideration ?
>>>
>>> Because we shouldn't override administrative settings of the MTU
>>> on the vlan device, unless we have to because of an MTU reduction
>>> on the underlying device.
>>>
>>> Yes this is not perfect if the admin never set an MTU to start with
>>> but as we don't have a way of telling whether the admin has or has
>>> not changed the MTU setting, the safest course of action is to do
>>> nothing in that case.
>> If the admin has changed the vlan device MTU smaller than the underlying
>> device MTU firstly, then changed the underlying device MTU smaller than
>> the vlan device MTU secondly. The admin's configuration has been overridden.
>> Can we consider that the admin's configuration for the vlan device MTU has
>> been invalid and disappeared after the second change? I think so.
> 
> The answer is no.
> 
> Herbert is saying:
> 
> ip link add link eth1 dev eth1.100 type vlan id 100
> ...
> ip link set eth1.100 mtu 800
> ..
> ip link set eth1 mtu 256
> ip link set eth1 mtu 1500
> 
> -> we do not want eth1.100 mtu being set back to 1500, this might
> break applications, depending on old kernel feature.
>  Eventually, setting back to 800 seems ok.

It seem that setting back to 800 more reasonable. We can record user
setting MTU by interface ndo_change_mtu() in struct vlan_dev_priv.

> 
> If you want this new feature, we need to record in eth1.100 device
> that no admin ever changed the mtu,
> as Herbert suggested.
> 
> Then, it is okay to upgrade the vlan mtu (but still is a behavioral
> change that _could_ break some scripts)
> 
> Thank you.
> .
>