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.174131.854361434090179436.davem@davemloft.net>
Date:   Fri, 17 Nov 2017 17:41:31 +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: Fri, 17 Nov 2017 19:34:27 +1100

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

So how exactly do the oversized packets get to the macvlan device from
the VM in this scenerio?  That detail seems to be missing from the
diagrams you provided earlier.  The VM and the macvlan boxes are just
connected with a line.

Thank you.