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] [day] [month] [year] [list]

Date:   Tue, 7 Jan 2020 23:30:09 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Shannon Nelson <snelson@...sando.io>,
        netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v2 net-next 3/4] ionic: restrict received packets to mtu size

Hi Andrew,

On Tue, 7 Jan 2020 at 21:46, Andrew Lunn <andrew@...n.ch> wrote:
>
> > Hi Andrew,
> >
>
> Hi Shannon
>
> > 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.
>
> Having played around with a few different NICs for DSA, it seems more
> like 75% don't care about the 'MRU' and will happily accept bigger
> frames.
>
> Anyway, it does not hurt to drop received frames bigger than what you
> can transmit.

In the general case, would we want a knob in Linux for the MRU, or is
it ok to go ahead with patches such as this one, and e.g. set up port
policers for limiting the frame length at the value of the MTU?

>
> Reviewed-by: Andrew Lunn <andrew@...n.ch>
>
>     Andrew

-Vladimir