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]

Message-ID: <112c6fd3-6565-e88a-dde5-520770d9f024@pensando.io>
Date:   Tue, 7 Jan 2020 10:00:49 -0800
From:   Shannon Nelson <snelson@...sando.io>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH v2 net-next 3/4] ionic: restrict received packets to mtu
 size

On 1/7/20 5:09 AM, Andrew Lunn wrote:
> 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
Hi Andrew,

In my experience the driver typically tells the NIC about the current 
max_frame size (e.g. MTU + ETH_HLEN), the NIC only copies max_frame 
bytes, and the NIC returns an error indication on a packets that had 
more than max_frame.

Before this patch we were telling the Naples NIC of buffers that are 
longer than max_frame.  This NIC will happily accept oversized packets 
off of the wire and copy as much as it can into the buffers, and it will 
only set an error status when it runs out of buffer, not when it goes 
above max_frame size.  To get the "correct" behavior, we can't rely on 
setting max_frame, we have to rely on the buffer indications.

sln