2019-05-23 17:14:38 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2007-12-17 06:06:41 +08:00
|
|
|
/* SCTP kernel reference Implementation
|
|
|
|
|
* Copyright (c) 1999-2001 Motorola, Inc.
|
|
|
|
|
* Copyright (c) 2001-2003 International Business Machines, Corp.
|
|
|
|
|
*
|
|
|
|
|
* This file is part of the SCTP kernel reference Implementation
|
|
|
|
|
*
|
|
|
|
|
* SCTP Checksum functions
|
|
|
|
|
*
|
|
|
|
|
* Please send any bug reports or fixes you make to the
|
|
|
|
|
* email address(es):
|
2013-07-23 20:51:47 +08:00
|
|
|
* lksctp developers <linux-sctp@vger.kernel.org>
|
2007-12-17 06:06:41 +08:00
|
|
|
*
|
|
|
|
|
* Written or modified by:
|
|
|
|
|
* Dinakaran Joseph
|
|
|
|
|
* Jon Grimm <jgrimm@us.ibm.com>
|
|
|
|
|
* Sridhar Samudrala <sri@us.ibm.com>
|
|
|
|
|
*
|
|
|
|
|
* Rewritten to use libcrc32c by:
|
|
|
|
|
* Vlad Yasevich <vladislav.yasevich@hp.com>
|
|
|
|
|
*/
|
|
|
|
|
|
2013-07-02 00:10:36 +08:00
|
|
|
#ifndef __sctp_checksum_h__
|
|
|
|
|
#define __sctp_checksum_h__
|
|
|
|
|
|
2007-12-17 06:06:41 +08:00
|
|
|
#include <linux/types.h>
|
|
|
|
|
#include <net/sctp/sctp.h>
|
|
|
|
|
#include <linux/crc32c.h>
|
net: sctp: fix and consolidate SCTP checksumming code
This fixes an outstanding bug found through IPVS, where SCTP packets
with skb->data_len > 0 (non-linearized) and empty frag_list, but data
accumulated in frags[] member, are forwarded with incorrect checksum
letting SCTP initial handshake fail on some systems. Linearizing each
SCTP skb in IPVS to prevent that would not be a good solution as
this leads to an additional and unnecessary performance penalty on
the load-balancer itself for no good reason (as we actually only want
to update the checksum, and can do that in a different/better way
presented here).
The actual problem is elsewhere, namely, that SCTP's checksumming
in sctp_compute_cksum() does not take frags[] into account like
skb_checksum() does. So while we are fixing this up, we better reuse
the existing code that we have anyway in __skb_checksum() and use it
for walking through the data doing checksumming. This will not only
fix this issue, but also consolidates some SCTP code with core
sk_buff code, bringing it closer together and removing respectively
avoiding reimplementation of skb_checksum() for no good reason.
As crc32c() can use hardware implementation within the crypto layer,
we leave that intact (it wraps around / falls back to e.g. slice-by-8
algorithm in __crc32c_le() otherwise); plus use the __crc32c_le_combine()
combinator for crc32c blocks.
Also, we remove all other SCTP checksumming code, so that we only
have to use sctp_compute_cksum() from now on; for doing that, we need
to transform SCTP checkumming in output path slightly, and can leave
the rest intact.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-10-30 18:50:52 +08:00
|
|
|
#include <linux/crc32.h>
|
2007-12-17 06:06:41 +08:00
|
|
|
|
net: sctp: fix and consolidate SCTP checksumming code
This fixes an outstanding bug found through IPVS, where SCTP packets
with skb->data_len > 0 (non-linearized) and empty frag_list, but data
accumulated in frags[] member, are forwarded with incorrect checksum
letting SCTP initial handshake fail on some systems. Linearizing each
SCTP skb in IPVS to prevent that would not be a good solution as
this leads to an additional and unnecessary performance penalty on
the load-balancer itself for no good reason (as we actually only want
to update the checksum, and can do that in a different/better way
presented here).
The actual problem is elsewhere, namely, that SCTP's checksumming
in sctp_compute_cksum() does not take frags[] into account like
skb_checksum() does. So while we are fixing this up, we better reuse
the existing code that we have anyway in __skb_checksum() and use it
for walking through the data doing checksumming. This will not only
fix this issue, but also consolidates some SCTP code with core
sk_buff code, bringing it closer together and removing respectively
avoiding reimplementation of skb_checksum() for no good reason.
As crc32c() can use hardware implementation within the crypto layer,
we leave that intact (it wraps around / falls back to e.g. slice-by-8
algorithm in __crc32c_le() otherwise); plus use the __crc32c_le_combine()
combinator for crc32c blocks.
Also, we remove all other SCTP checksumming code, so that we only
have to use sctp_compute_cksum() from now on; for doing that, we need
to transform SCTP checkumming in output path slightly, and can leave
the rest intact.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-10-30 18:50:52 +08:00
|
|
|
static inline __wsum sctp_csum_update(const void *buff, int len, __wsum sum)
|
2007-12-17 06:06:41 +08:00
|
|
|
{
|
net: sctp: fix and consolidate SCTP checksumming code
This fixes an outstanding bug found through IPVS, where SCTP packets
with skb->data_len > 0 (non-linearized) and empty frag_list, but data
accumulated in frags[] member, are forwarded with incorrect checksum
letting SCTP initial handshake fail on some systems. Linearizing each
SCTP skb in IPVS to prevent that would not be a good solution as
this leads to an additional and unnecessary performance penalty on
the load-balancer itself for no good reason (as we actually only want
to update the checksum, and can do that in a different/better way
presented here).
The actual problem is elsewhere, namely, that SCTP's checksumming
in sctp_compute_cksum() does not take frags[] into account like
skb_checksum() does. So while we are fixing this up, we better reuse
the existing code that we have anyway in __skb_checksum() and use it
for walking through the data doing checksumming. This will not only
fix this issue, but also consolidates some SCTP code with core
sk_buff code, bringing it closer together and removing respectively
avoiding reimplementation of skb_checksum() for no good reason.
As crc32c() can use hardware implementation within the crypto layer,
we leave that intact (it wraps around / falls back to e.g. slice-by-8
algorithm in __crc32c_le() otherwise); plus use the __crc32c_le_combine()
combinator for crc32c blocks.
Also, we remove all other SCTP checksumming code, so that we only
have to use sctp_compute_cksum() from now on; for doing that, we need
to transform SCTP checkumming in output path slightly, and can leave
the rest intact.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-10-30 18:50:52 +08:00
|
|
|
/* This uses the crypto implementation of crc32c, which is either
|
|
|
|
|
* implemented w/ hardware support or resolves to __crc32c_le().
|
2007-12-17 06:06:41 +08:00
|
|
|
*/
|
2017-11-26 20:16:07 +08:00
|
|
|
return (__force __wsum)crc32c((__force __u32)sum, buff, len);
|
2007-12-17 06:06:41 +08:00
|
|
|
}
|
|
|
|
|
|
net: sctp: fix and consolidate SCTP checksumming code
This fixes an outstanding bug found through IPVS, where SCTP packets
with skb->data_len > 0 (non-linearized) and empty frag_list, but data
accumulated in frags[] member, are forwarded with incorrect checksum
letting SCTP initial handshake fail on some systems. Linearizing each
SCTP skb in IPVS to prevent that would not be a good solution as
this leads to an additional and unnecessary performance penalty on
the load-balancer itself for no good reason (as we actually only want
to update the checksum, and can do that in a different/better way
presented here).
The actual problem is elsewhere, namely, that SCTP's checksumming
in sctp_compute_cksum() does not take frags[] into account like
skb_checksum() does. So while we are fixing this up, we better reuse
the existing code that we have anyway in __skb_checksum() and use it
for walking through the data doing checksumming. This will not only
fix this issue, but also consolidates some SCTP code with core
sk_buff code, bringing it closer together and removing respectively
avoiding reimplementation of skb_checksum() for no good reason.
As crc32c() can use hardware implementation within the crypto layer,
we leave that intact (it wraps around / falls back to e.g. slice-by-8
algorithm in __crc32c_le() otherwise); plus use the __crc32c_le_combine()
combinator for crc32c blocks.
Also, we remove all other SCTP checksumming code, so that we only
have to use sctp_compute_cksum() from now on; for doing that, we need
to transform SCTP checkumming in output path slightly, and can leave
the rest intact.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-10-30 18:50:52 +08:00
|
|
|
static inline __wsum sctp_csum_combine(__wsum csum, __wsum csum2,
|
|
|
|
|
int offset, int len)
|
2007-12-17 06:06:41 +08:00
|
|
|
{
|
2017-11-26 20:16:07 +08:00
|
|
|
return (__force __wsum)__crc32c_le_combine((__force __u32)csum,
|
|
|
|
|
(__force __u32)csum2, len);
|
2007-12-17 06:06:41 +08:00
|
|
|
}
|
2013-07-02 00:10:36 +08:00
|
|
|
|
2013-07-25 09:52:05 +08:00
|
|
|
static inline __le32 sctp_compute_cksum(const struct sk_buff *skb,
|
|
|
|
|
unsigned int offset)
|
|
|
|
|
{
|
2019-03-18 19:47:00 +08:00
|
|
|
struct sctphdr *sh = (struct sctphdr *)(skb->data + offset);
|
net: sctp: fix and consolidate SCTP checksumming code
This fixes an outstanding bug found through IPVS, where SCTP packets
with skb->data_len > 0 (non-linearized) and empty frag_list, but data
accumulated in frags[] member, are forwarded with incorrect checksum
letting SCTP initial handshake fail on some systems. Linearizing each
SCTP skb in IPVS to prevent that would not be a good solution as
this leads to an additional and unnecessary performance penalty on
the load-balancer itself for no good reason (as we actually only want
to update the checksum, and can do that in a different/better way
presented here).
The actual problem is elsewhere, namely, that SCTP's checksumming
in sctp_compute_cksum() does not take frags[] into account like
skb_checksum() does. So while we are fixing this up, we better reuse
the existing code that we have anyway in __skb_checksum() and use it
for walking through the data doing checksumming. This will not only
fix this issue, but also consolidates some SCTP code with core
sk_buff code, bringing it closer together and removing respectively
avoiding reimplementation of skb_checksum() for no good reason.
As crc32c() can use hardware implementation within the crypto layer,
we leave that intact (it wraps around / falls back to e.g. slice-by-8
algorithm in __crc32c_le() otherwise); plus use the __crc32c_le_combine()
combinator for crc32c blocks.
Also, we remove all other SCTP checksumming code, so that we only
have to use sctp_compute_cksum() from now on; for doing that, we need
to transform SCTP checkumming in output path slightly, and can leave
the rest intact.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-10-30 18:50:52 +08:00
|
|
|
const struct skb_checksum_ops ops = {
|
|
|
|
|
.update = sctp_csum_update,
|
|
|
|
|
.combine = sctp_csum_combine,
|
|
|
|
|
};
|
2017-11-26 20:16:07 +08:00
|
|
|
__le32 old = sh->checksum;
|
|
|
|
|
__wsum new;
|
2013-07-25 09:52:05 +08:00
|
|
|
|
net: sctp: fix and consolidate SCTP checksumming code
This fixes an outstanding bug found through IPVS, where SCTP packets
with skb->data_len > 0 (non-linearized) and empty frag_list, but data
accumulated in frags[] member, are forwarded with incorrect checksum
letting SCTP initial handshake fail on some systems. Linearizing each
SCTP skb in IPVS to prevent that would not be a good solution as
this leads to an additional and unnecessary performance penalty on
the load-balancer itself for no good reason (as we actually only want
to update the checksum, and can do that in a different/better way
presented here).
The actual problem is elsewhere, namely, that SCTP's checksumming
in sctp_compute_cksum() does not take frags[] into account like
skb_checksum() does. So while we are fixing this up, we better reuse
the existing code that we have anyway in __skb_checksum() and use it
for walking through the data doing checksumming. This will not only
fix this issue, but also consolidates some SCTP code with core
sk_buff code, bringing it closer together and removing respectively
avoiding reimplementation of skb_checksum() for no good reason.
As crc32c() can use hardware implementation within the crypto layer,
we leave that intact (it wraps around / falls back to e.g. slice-by-8
algorithm in __crc32c_le() otherwise); plus use the __crc32c_le_combine()
combinator for crc32c blocks.
Also, we remove all other SCTP checksumming code, so that we only
have to use sctp_compute_cksum() from now on; for doing that, we need
to transform SCTP checkumming in output path slightly, and can leave
the rest intact.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-10-30 18:50:52 +08:00
|
|
|
sh->checksum = 0;
|
2017-11-26 20:16:07 +08:00
|
|
|
new = ~__skb_checksum(skb, offset, skb->len - offset, ~(__wsum)0, &ops);
|
net: sctp: fix and consolidate SCTP checksumming code
This fixes an outstanding bug found through IPVS, where SCTP packets
with skb->data_len > 0 (non-linearized) and empty frag_list, but data
accumulated in frags[] member, are forwarded with incorrect checksum
letting SCTP initial handshake fail on some systems. Linearizing each
SCTP skb in IPVS to prevent that would not be a good solution as
this leads to an additional and unnecessary performance penalty on
the load-balancer itself for no good reason (as we actually only want
to update the checksum, and can do that in a different/better way
presented here).
The actual problem is elsewhere, namely, that SCTP's checksumming
in sctp_compute_cksum() does not take frags[] into account like
skb_checksum() does. So while we are fixing this up, we better reuse
the existing code that we have anyway in __skb_checksum() and use it
for walking through the data doing checksumming. This will not only
fix this issue, but also consolidates some SCTP code with core
sk_buff code, bringing it closer together and removing respectively
avoiding reimplementation of skb_checksum() for no good reason.
As crc32c() can use hardware implementation within the crypto layer,
we leave that intact (it wraps around / falls back to e.g. slice-by-8
algorithm in __crc32c_le() otherwise); plus use the __crc32c_le_combine()
combinator for crc32c blocks.
Also, we remove all other SCTP checksumming code, so that we only
have to use sctp_compute_cksum() from now on; for doing that, we need
to transform SCTP checkumming in output path slightly, and can leave
the rest intact.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-10-30 18:50:52 +08:00
|
|
|
sh->checksum = old;
|
2013-07-25 09:52:05 +08:00
|
|
|
|
2017-11-26 20:16:07 +08:00
|
|
|
return cpu_to_le32((__force __u32)new);
|
2013-07-25 09:52:05 +08:00
|
|
|
}
|
|
|
|
|
|
2013-07-02 00:10:36 +08:00
|
|
|
#endif /* __sctp_checksum_h__ */
|