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 03:39:33 -0500
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     David Ahern <dahern@...italocean.com>, netdev@...r.kernel.org
Subject: Re: virtio_net: can change MTU after installing program

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? 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.

-- 
MST