netdev - RE: [Patch net v2] mlx5: fixup checksum for short ethernet frame padding

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, 22 Jan 2019 11:35:51 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Saeed Mahameed' <saeedm@....mellanox.co.il>,
        Christoph Paasch <christoph.paasch@...il.com>
CC:     Nikola Ciprich <nikola.ciprich@...uxbox.cz>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>
Subject: RE: [Patch net v2] mlx5: fixup checksum for short ethernet frame
 padding

From: Saeed Mahameed
> Sent: 19 January 2019 00:46
> On Thu, Jan 17, 2019 at 5:19 PM Christoph Paasch
> <christoph.paasch@...il.com> wrote:
> >
> > Hello,
> >
> > On Sun, Jan 6, 2019 at 3:12 AM Saeed Mahameed <saeedm@....mellanox.co.il> wrote:
> > >
> > > On Sat, Jan 5, 2019 at 8:35 PM Nikola Ciprich
> > > <nikola.ciprich@...uxbox.cz> wrote:
> > > >
> > > > Hi Saeed,
> > > >
> > > >
> > > > > Most likely the same issue, we are finalizing the patch initially
> > > > > proposed by Cong, you can find it here, I plan to submit it next week,
> > > > > after all the regression tests.
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git/commit/?h=topic/csum-fix
> > > > >
> > > > > It would be nice if you verify this fixes your issue.
> > > >
> > > > I tried 4.20.0 + this fix and the problems are gone! haven't done backport to 4.19 yet.
> > > >
> > > > cheers!
> > >
> > > Thanks nik for your input, we will submit a similar fix very soon.
> >
> > We are also seeing similar issues on v4.14.94, as Eric's patch got
> > backported with 6bf32cda46eb.
> >
> > I backported (had to do some changes to solve the conflicts) your fix
> > from topic/csum-fix to v4.14.94, but then I still get the warning when
> > the frame is bigger than ETH_ZLEN (which is quite unsurprising ;-)).
> 
> Hi Christoph,
> This is a bummer, we only saw the issue with switches that are padding
> packets up to ETH_ZLEN,
> and they never touch packets larger than this size, still i agree that
> the issue could happen with any
> packet size, we just never saw such hardware/switch which produces
> packets with non-zero end padding!
> 
> the only option i can suggest is to disable checksum complete, it can
> be done via a priv-flag which was submitted
> to kernel v4.20.

I'm not at all sure it is valid to add 'random' padding to long ethernet frames.
Certainly LLC frames (with a length not an ethertype) must not be padded
  (beyond the minimum frame size).
If the ethertype is IP then the data nominally ends at the ethernet CRC.
For IP frame padding can only be detected if the IP datagram ends in the ethernet frame.
(Wireshark has a protocol decode configured for padding in IP frames.)
For other ethertypes you'd need to look at the specific protocol specification.

Notwithstanding the above, if the hardware is checksumming the entire packet
then to validate the UDP/TCP checksum you need to remove the checksum of
any discarded 'padding' bytes as well that that of the header.

We had an issue recently where a VM configuration (I could find out which)
was padding all ethernet frames to an even number of bytes.
This caused grief for some hardware that (for an unknown reason) was
assuming the IP datagram length matched the frame length.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)