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: <20170818150358.GA3258@lunn.ch>
Date:   Fri, 18 Aug 2017 17:03:58 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Salil Mehta <salil.mehta@...wei.com>
Cc:     "davem@...emloft.net" <davem@...emloft.net>,
        "Zhuangyuzeng (Yisen)" <yisen.zhuang@...wei.com>,
        "lipeng (Y)" <lipeng321@...wei.com>,
        "dan.carpenter@...cle.com" <dan.carpenter@...cle.com>,
        "mehta.salil.lnk@...il.com" <mehta.salil.lnk@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        Linuxarm <linuxarm@...wei.com>
Subject: Re: [PATCH net-next] net: hns3: Add support to change MTU in
 hardware & netdev

> > > +	/* MTU range: 68 - 9706 */
> > > +	netdev->min_mtu = ETH_MIN_MTU;
> > 
> > http://elixir.free-
> > electrons.com/linux/latest/source/net/ethernet/eth.c#L361
> Supported range of Min and Max MTU should be at the discretion
> of the driver. Therefore, initialization looks fine to me.
> 
> I could not clearly understand the problem being highlighted
> over here. Could you further clarify?

This is already setting min_mtu to ETH_MIN_MTU. There is no need for
you to set it.

> > >  #define HNS3_RING_MAX_PENDING			32768
> > > +#define HNS3_MAX_MTU				9728
> > 
> > It seems odd that it does not already exists somewhere. The core does
> > not enforce the MTU.  You could be passed a frame which is bigger. So
> > you should check before trying to pass something to the hardware which
> > the hardware cannot handle.
> There is a check already in place for this as well since 4.10-rc1.

Yes, the core will check when changing the MTU.

But when passing frames to be transmitted, it does not check the frame
fits the MTU.  DSA actually makes use of this, when passing frames to
an Ethernet switch attached to the interface. We need to add an extra
header to the frame, which makes the frame bigger than the MTU. Most
Ethernet drivers are happy with this, they send the frame. Other
reject it, and we have had to make driver changes. And some just
explode :-(

If 9728 is a hard limit for your device, you should check when passed
a frame to make sure it is actually <= 9728 bytes in length.

     Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ