netdev - Re: virtio_net: can change MTU after installing program

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]

Message-ID: <87lfopznfe.fsf@toke.dk>
Date:   Wed, 26 Feb 2020 10:51:33 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>,
        David Ahern <dahern@...italocean.com>
Cc:     Jason Wang <jasowang@...hat.com>,
        "netdev\@vger.kernel.org" <netdev@...r.kernel.org>
Subject: Re: virtio_net: can change MTU after installing program

"Michael S. Tsirkin" <mst@...hat.com> writes:

> On Tue, Feb 25, 2020 at 08:32:14PM -0700, David Ahern wrote:
>> Another issue is that virtio_net checks the MTU when a program is
>> installed, but does not restrict an MTU change after:
>> 
>> # ip li sh dev eth0
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 xdp qdisc fq_codel
>> state UP mode DEFAULT group default qlen 1000
>>     link/ether 5a:39:e6:01:a5:36 brd ff:ff:ff:ff:ff:ff
>>     prog/xdp id 13 tag c5595e4590d58063 jited
>> 
>> # ip li set dev eth0 mtu 8192
>> 
>> # ip li sh dev eth0
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8192 xdp qdisc fq_codel
>> state UP mode DEFAULT group default qlen 1000
>> 
>> 
>
> Cc Toke who has tested this on other cards and has some input.

Well, my comment was just that we already restrict MTU changes on mlx5
when an XDP program is loaded:

$ sudo ip link set dev ens1f1 mtu 8192
RTNETLINK answers: Invalid argument

Reading through the rest of the thread I don't have any strong opinions
about whether this should propagate out from the host or not. I suspect
it would not be worth the trouble, though, and as you say it's already
possible to configure regular network devices in a way that is
incompatible with the rest of the network.

-Toke