netdev - Re: [PATCH] macvlan: verify MTU before lowerdev xmit

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: <871skxgv70.fsf@linkitivity.dja.id.au>
Date:   Fri, 17 Nov 2017 19:34:27 +1100
From:   Daniel Axtens <dja@...ens.net>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, shannon.nelson@...cle.com
Subject: Re: [PATCH] macvlan: verify MTU before lowerdev xmit

Hi Dave,

> This is an area where we really haven't set down some clear rules
> for behavior.
>
> If an interface has a particular MTU, it must be able to successfully
> send MTU sized packets on that link be it virtual or physical.
>
> Only a "next hop" can have a different MTU and thus drop packets.
> This requirement is absolutely necessary in order for proper
> signalling (path MTU messages) to make their way back to the sending
> host.
>
> In this VM-->macvlan case it's more like a point to point connection
> and there lacks a "next hop" to serve and the provider of proper
> signalling.
>
> This whole situation seems to be handled quite poorly in virtualized
> setups.  Allowing one end of the virtual networking "link" into the
> guest have a different MTU from the other end is a HUGE mistake.

I agree, but users do it, so I'm just trying to figure out the best way
to handle it. Currently the bridge code and openvswitch will detect when
a large packet arrives and drop the packet* - the bridge code with
is_skb_forwardable() and openvswitch with it's own approach in
vport.c. This patch tries to bring macvlan in line with those.

*except for GSO packets - they are assumed to be ok, which isn't always
 true. I am working on some patches for this - but my approach may need
 to be changed in light of what you're saying.

> There needs to be control path signalling between the guest and the
> provider of the virtual link so that they can synchronize their MTU
> settings.

We have these sorts of problems on probably every type of virtual
interface, some of which are easier to deal with than others. I'm
particularly worried about interfaces like ibmveth where the 'other end'
is usually an AIX partition on a big powerpc system. AIX tends to bring
up these interfaces with MTUs of around 64k as well. (This is what
originially got me down the rabbit hole of caring about mismatched-MTU
handling!)

> Yes this is hard, but what is happening now doesn't fly in the long
> term.

I'm at a bit of a loss about how we would do a proper fix. The only
thing that comes to mind would be for the receive routines of the
virtual network interfaces to check the size of incoming packets, but -
if I understand correctly - we would need to know what the maximum size
for a recieved packet should be.

Regards,
Daniel