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: <20171117.145401.1277591015464586683.davem@davemloft.net>
Date:   Fri, 17 Nov 2017 14:54:01 +0900 (KST)
From:   David Miller <davem@...emloft.net>
To:     dja@...ens.net
Cc:     netdev@...r.kernel.org, shannon.nelson@...cle.com
Subject: Re: [PATCH] macvlan: verify MTU before lowerdev xmit

From: Daniel Axtens <dja@...ens.net>
Date: Tue, 14 Nov 2017 21:32:51 +1100

> If a macvlan device which is not in bridge mode receives a packet,
> it is sent straight to the lowerdev without checking against the
> device's MTU. This also happens for multicast traffic.
> 
> Add an is_skb_forwardable() check against the lowerdev before
> sending the packet out through it. I think this is the simplest
> and best way to do it, and is consistent with the use of
> dev_forward_skb() in the bridge path.
> 
> This is easy to replicate:
>  - create a VM with a macvtap connection in private mode
>  - set the lowerdev MTU to something low in the host (e.g. 1480)
>  - do not set the MTU lower in the guest (e.g. keep at 1500)
>  - netperf to a different host with the same high MTU
>  - observe that currently, the driver will forward too-big packets
>  - observe that with this patch the packets are dropped
> 
> Cc: Shannon Nelson <shannon.nelson@...cle.com>
> Signed-off-by: Daniel Axtens <dja@...ens.net>

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.

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.

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