netdev - Re: [PATCH v2 net-next 3/4] ionic: restrict received packets to mtu size

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:   Tue, 7 Jan 2020 14:09:49 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Shannon Nelson <snelson@...sando.io>
Cc:     netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH v2 net-next 3/4] ionic: restrict received packets to mtu
 size

On Mon, Jan 06, 2020 at 07:43:48PM -0800, Shannon Nelson wrote:
> Make sure the NIC drops packets that are larger than the
> specified MTU.
> 
> The front end of the NIC will accept packets larger than MTU and
> will copy all the data it can to fill up the driver's posted
> buffers - if the buffers are not long enough the packet will
> then get dropped.  With the Rx SG buffers allocagted as full
> pages, we are currently setting up more space than MTU size
> available and end up receiving some packets that are larger
> than MTU, up to the size of buffers posted.  To be sure the
> NIC doesn't waste our time with oversized packets we need to
> lie a little in the SG descriptor about how long is the last
> SG element.

Hi Shannon

Does the stack really drop them later? With DSA, the frame has an
additional header, making it longer than the MTU. Most of the NICs
i've used are happy to receive such frames. So it does seem common
practice to not implement a 'MRU' in the MAC.

If the stack really does drop them, this is a reasonable optimisation.

Thanks

	Andrew