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]

Date:   Wed, 26 Feb 2020 17:30:18 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     David Ahern <dahern@...italocean.com>, netdev@...r.kernel.org
Subject: Re: virtio_net: can change MTU after installing program


On 2020/2/26 下午4:39, Michael S. Tsirkin wrote:
> On Wed, Feb 26, 2020 at 02:37:01AM -0500, Jason Wang wrote:
>>
>> ----- Original Message -----
>>> 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
>>> Well the reason XDP wants to limit MTU is this:
>>>      the MTU must be less than a page
>>>      size to avoid having to handle XDP across multiple pages
>>>
>> But even if we limit MTU is guest there's no way to limit the packet
>> size on host.
> Isn't this fundamental? IIUC dev->mtu is mostly a hint to devices about
> how the network is configured. It has to be the same across LAN.  If
> someone misconfigures it that breaks networking, and user gets to keep
> both pieces. E.g. e1000 will use dev->mtu to calculate rx buffer size.
> If you make it too small, well packets that are too big get dropped.
> There's no magic to somehow make them smaller, or anything like that.
> We can certainly drop packet > dev->mtu in the driver right now if we want to,
> and maybe if it somehow becomes important for performance, we
> could teach host to drop such packets for us. Though
> I don't really see why we care ...
>
>> It looks to me we need to introduce new commands to
>> change the backend MTU (e.g TAP) accordingly.
>>
>> Thanks
> So you are saying there are configurations where host does not know the
> correct MTU, and needs guest's help to figure it out?


Yes.


> I guess it's
> possible but it seems beside the point raised here.  TAP in particular
> mostly just seems to ignore MTU, I am not sure why we should bother
> propagating it there from guest or host. Propagating it from guest to
> the actual NIC might be useful e.g. for buffer sizing, but is tricky
> to do safely in case the NIC is shared between VMs.


Macvlan passthrough mode could be easier I guess.

Thanks