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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0b446fc3-01ed-4dc1-81f0-ef0e1e2cadb0@digitalocean.com>
Date:   Wed, 26 Feb 2020 09:03:47 -0700
From:   David Ahern <dahern@...italocean.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>
Cc:     Jason Wang <jasowang@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: virtio_net: can change MTU after installing program

On 2/26/20 2:51 AM, Toke Høiland-Jørgensen wrote:
> "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.
> 

Both mlx5 and sfc restrict MTU change to XDP limits; virtio does not
which strikes me as a problem.