netdev - Re: [PATCH v1 1/1] veth: Do not drop packets larger then the mtu set on the receiving side

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ae79f91f-dd35-5ce8-95e4-5906a9a40160@lab.ntt.co.jp>
Date:   Fri, 11 Jan 2019 13:22:22 +0900
From:   Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
To:     Fredrik Gustavsson <gustfred@...il.com>, netdev@...r.kernel.org,
        davem@...emloft.net, daniel@...earbox.net
Subject: Re: [PATCH v1 1/1] veth: Do not drop packets larger then the mtu set
 on the receiving side

On 2019/01/10 22:26, Fredrik Gustavsson wrote:
> commit affede4a779420bd8510ab937251a3796d3228df
> Author: Fredrik Gustavsson <gustfred@...il.com>
> Date:   Tue Jan 8 11:21:39 2019 +0100
> 
> veth: Do not drop packets larger then the mtu set on the receiving side
> 
> Currently veth drops all packets larger then the mtu set on the receiving
> end of the pair. This is inconsistent with most hardware ethernet drivers
> that happily receives packets up the the ethernet MTU independent of the
> configured MTU.
> 
> There should not be a need for dropping IP packets at receiver with
> size > configured IP MTU, IP MTU is for fragmentation at sender side.
> And IP packets with size > receiver L2 MTU will be dropped at sub-IP layer.

But with current veth behavior setting MTU effectively sets MRU as well.
This may be being used to drop unexpectedly long packets e.g. from
containers on container host. If we unconditionally change this behavior
it can cause regression on some environment. This should be an option at
least.

BTW there was a similar precedent attempt. You might want to take a look.

https://www.mail-archive.com/netdev@vger.kernel.org/msg167636.html
https://www.mail-archive.com/netdev@vger.kernel.org/msg167899.html

-- 
Toshiaki Makita