netdev - RE: [RFC PATCH net-next 2/5] net: split skb_checksum

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: <063D6719AE5E284EB5DD2968C1650D6DB026CEA4@AcuExch.aculab.com>
Date:   Tue, 24 Jan 2017 16:35:20 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Tom Herbert' <tom@...bertland.com>,
        Davide Caratti <dcaratti@...hat.com>
CC:     "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Subject: RE: [RFC PATCH net-next 2/5] net: split skb_checksum_help

From: Tom Herbert
> Sent: 23 January 2017 21:00
..
> skb_checksum_help is specific to the Internet checksum. For instance,
> CHECKSUM_COMPLETE can _only_ refer to Internet checksum calculation
> nothing else will work. Checksums and CRCs are very different things
> with very different processing. They are not interchangeable, have
> very different properties, and hence it is a mistake to try to shoe
> horn things so that they use a common infrastructure.
> 
> It might make sense to create some CRC helper functions, but last time
> I checked there are so few users of CRC in skbufs I'm not even sure
> that would make sense.

I can imagine horrid things happening if someone tries to encapsulate
SCTP/IP in UDP (or worse UDP/IP in SCTP).

For UDP in UDP I suspect that CHECKSUM_COMPLETE on an inner UDP packet
allows the outer checksum be calculated by ignoring the inner packet
(since it sums to zero).
This just isn't true if SCTP is involved.
There are tricks to generate a crc of a longer packet, but they'd only
work for SCTP in SCTP.

For non-encapsulated packets it is a different matter.

	David