david/ipxe
david
/
ipxe
Archived
1
0
Fork 0
This repository has been archived on 2020-12-06. You can view files and clone it, but cannot push or open issues or pull requests.
ipxe/src/include/ipxe/tcpip.h

212 lines
6.6 KiB
C
Raw Normal View History

#ifndef _IPXE_TCPIP_H
#define _IPXE_TCPIP_H
/** @file
*
* Transport-network layer interface
*
*/
FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL );
#include <stdint.h>
#include <ipxe/socket.h>
#include <ipxe/in.h>
#include <ipxe/tables.h>
#include <bits/tcpip.h>
struct io_buffer;
struct net_device;
struct ip_statistics;
[tcpip] Avoid generating positive zero for transmitted UDP checksums TCP/IP checksum fields are one's complement values and therefore have two possible representations of zero: positive zero (0x0000) and negative zero (0xffff). In RFC768, UDP over IPv4 exploits this redundancy to repurpose the positive representation of zero (0x0000) to mean "no checksum calculated"; checksums are optional for UDP over IPv4. In RFC2460, checksums are made mandatory for UDP over IPv4. The wording of the RFC is such that the UDP header is mandated to use only the negative representation of zero (0xffff), rather than simply requiring the checksum to be correct but allowing for either representation of zero to be used. In RFC1071, an example algorithm is given for calculating the TCP/IP checksum. This algorithm happens to produce only the positive representation of zero (0x0000); this is an artifact of the way that unsigned arithmetic is used to calculate a signed one's complement sum (and its final negation). A common misconception has developed (exemplified in RFC1624) that this artifact is part of the specification. Many people have assumed that the checksum field should never contain the negative representation of zero (0xffff). A sensible receiver will calculate the checksum over the whole packet and verify that the result is zero (in whichever representation of zero happens to be generated by the receiver's algorithm). Such a receiver will not care which representation of zero happens to be used in the checksum field. However, there are receivers in existence which will verify the received checksum the hard way: by calculating the checksum over the remainder of the packet and comparing the result against the checksum field. If the representation of zero used by the receiver's algorithm does not match the representation of zero used by the transmitter (and so placed in the checksum field), and if the receiver does not explicitly allow for both representations to compare as equal, then the receiver may reject packets with a valid checksum. For UDP, the combined RFCs effectively mandate that we should generate only the negative representation of zero in the checksum field. For IP, TCP and ICMP, the RFCs do not mandate which representation of zero should be used, but the misconceptions which have grown up around RFC1071 and RFC1624 suggest that it would be least surprising to generate only the positive representation of zero in the checksum field. Fix by ensuring that all of our checksum algorithms generate only the positive representation of zero, and explicitly inverting this in the case of transmitted UDP packets. Reported-by: Wissam Shoukair <wissams@mellanox.com> Tested-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-09-10 14:19:16 +02:00
/** Positive zero checksum value */
#define TCPIP_POSITIVE_ZERO_CSUM 0x0000
/** Negative zero checksum value */
#define TCPIP_NEGATIVE_ZERO_CSUM 0xffff
/** Empty checksum value
*
[tcpip] Avoid generating positive zero for transmitted UDP checksums TCP/IP checksum fields are one's complement values and therefore have two possible representations of zero: positive zero (0x0000) and negative zero (0xffff). In RFC768, UDP over IPv4 exploits this redundancy to repurpose the positive representation of zero (0x0000) to mean "no checksum calculated"; checksums are optional for UDP over IPv4. In RFC2460, checksums are made mandatory for UDP over IPv4. The wording of the RFC is such that the UDP header is mandated to use only the negative representation of zero (0xffff), rather than simply requiring the checksum to be correct but allowing for either representation of zero to be used. In RFC1071, an example algorithm is given for calculating the TCP/IP checksum. This algorithm happens to produce only the positive representation of zero (0x0000); this is an artifact of the way that unsigned arithmetic is used to calculate a signed one's complement sum (and its final negation). A common misconception has developed (exemplified in RFC1624) that this artifact is part of the specification. Many people have assumed that the checksum field should never contain the negative representation of zero (0xffff). A sensible receiver will calculate the checksum over the whole packet and verify that the result is zero (in whichever representation of zero happens to be generated by the receiver's algorithm). Such a receiver will not care which representation of zero happens to be used in the checksum field. However, there are receivers in existence which will verify the received checksum the hard way: by calculating the checksum over the remainder of the packet and comparing the result against the checksum field. If the representation of zero used by the receiver's algorithm does not match the representation of zero used by the transmitter (and so placed in the checksum field), and if the receiver does not explicitly allow for both representations to compare as equal, then the receiver may reject packets with a valid checksum. For UDP, the combined RFCs effectively mandate that we should generate only the negative representation of zero in the checksum field. For IP, TCP and ICMP, the RFCs do not mandate which representation of zero should be used, but the misconceptions which have grown up around RFC1071 and RFC1624 suggest that it would be least surprising to generate only the positive representation of zero in the checksum field. Fix by ensuring that all of our checksum algorithms generate only the positive representation of zero, and explicitly inverting this in the case of transmitted UDP packets. Reported-by: Wissam Shoukair <wissams@mellanox.com> Tested-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-09-10 14:19:16 +02:00
* All of our TCP/IP checksum algorithms will return only the positive
* representation of zero (0x0000) for a zero checksum over non-zero
* input data. This property arises since the end-around carry used
* to mimic one's complement addition using unsigned arithmetic
* prevents the running total from ever returning to 0x0000. The
* running total will therefore use only the negative representation
* of zero (0xffff). Since the return value is the one's complement
* negation of the running total (calculated by simply bit-inverting
* the running total), the return value will therefore use only the
* positive representation of zero (0x0000).
*
* It is a very common misconception (found in many places such as
* RFC1624) that this is a property guaranteed by the underlying
* mathematics. It is not; the choice of which zero representation is
* used is merely an artifact of the software implementation of the
* checksum algorithm.
*
* For consistency, we choose to use the positive representation of
* zero (0x0000) for the checksum of a zero-length block of data.
* This ensures that all of our TCP/IP checksum algorithms will return
* only the positive representation of zero (0x0000) for a zero
* checksum (regardless of the input data).
*/
[tcpip] Avoid generating positive zero for transmitted UDP checksums TCP/IP checksum fields are one's complement values and therefore have two possible representations of zero: positive zero (0x0000) and negative zero (0xffff). In RFC768, UDP over IPv4 exploits this redundancy to repurpose the positive representation of zero (0x0000) to mean "no checksum calculated"; checksums are optional for UDP over IPv4. In RFC2460, checksums are made mandatory for UDP over IPv4. The wording of the RFC is such that the UDP header is mandated to use only the negative representation of zero (0xffff), rather than simply requiring the checksum to be correct but allowing for either representation of zero to be used. In RFC1071, an example algorithm is given for calculating the TCP/IP checksum. This algorithm happens to produce only the positive representation of zero (0x0000); this is an artifact of the way that unsigned arithmetic is used to calculate a signed one's complement sum (and its final negation). A common misconception has developed (exemplified in RFC1624) that this artifact is part of the specification. Many people have assumed that the checksum field should never contain the negative representation of zero (0xffff). A sensible receiver will calculate the checksum over the whole packet and verify that the result is zero (in whichever representation of zero happens to be generated by the receiver's algorithm). Such a receiver will not care which representation of zero happens to be used in the checksum field. However, there are receivers in existence which will verify the received checksum the hard way: by calculating the checksum over the remainder of the packet and comparing the result against the checksum field. If the representation of zero used by the receiver's algorithm does not match the representation of zero used by the transmitter (and so placed in the checksum field), and if the receiver does not explicitly allow for both representations to compare as equal, then the receiver may reject packets with a valid checksum. For UDP, the combined RFCs effectively mandate that we should generate only the negative representation of zero in the checksum field. For IP, TCP and ICMP, the RFCs do not mandate which representation of zero should be used, but the misconceptions which have grown up around RFC1071 and RFC1624 suggest that it would be least surprising to generate only the positive representation of zero in the checksum field. Fix by ensuring that all of our checksum algorithms generate only the positive representation of zero, and explicitly inverting this in the case of transmitted UDP packets. Reported-by: Wissam Shoukair <wissams@mellanox.com> Tested-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-09-10 14:19:16 +02:00
#define TCPIP_EMPTY_CSUM TCPIP_POSITIVE_ZERO_CSUM
/** TCP/IP address flags */
enum tcpip_st_flags {
/** Bind to a privileged port (less than 1024)
*
* This value is chosen as 1024 to optimise the calculations
* in tcpip_bind().
*/
TCPIP_BIND_PRIVILEGED = 0x0400,
};
/**
* TCP/IP socket address
*
* This contains the fields common to socket addresses for all TCP/IP
* address families.
*/
struct sockaddr_tcpip {
/** Socket address family (part of struct @c sockaddr) */
sa_family_t st_family;
/** Flags */
uint16_t st_flags;
/** TCP/IP port */
uint16_t st_port;
/** Scope ID
*
* For link-local or multicast addresses, this is the network
* device index.
*/
uint16_t st_scope_id;
/** Padding
*
* This ensures that a struct @c sockaddr_tcpip is large
* enough to hold a socket address for any TCP/IP address
* family.
*/
char pad[ sizeof ( struct sockaddr ) -
( sizeof ( sa_family_t ) /* st_family */ +
sizeof ( uint16_t ) /* st_flags */ +
sizeof ( uint16_t ) /* st_port */ +
sizeof ( uint16_t ) /* st_scope_id */ ) ];
} __attribute__ (( packed, may_alias ));
/**
* A transport-layer protocol of the TCP/IP stack (eg. UDP, TCP, etc)
*/
struct tcpip_protocol {
/** Protocol name */
const char *name;
/**
* Process received packet
*
* @v iobuf I/O buffer
* @v netdev Network device
* @v st_src Partially-filled source address
* @v st_dest Partially-filled destination address
* @v pshdr_csum Pseudo-header checksum
* @ret rc Return status code
*
* This method takes ownership of the I/O buffer.
*/
int ( * rx ) ( struct io_buffer *iobuf, struct net_device *netdev,
struct sockaddr_tcpip *st_src,
struct sockaddr_tcpip *st_dest, uint16_t pshdr_csum );
[tcpip] Avoid generating positive zero for transmitted UDP checksums TCP/IP checksum fields are one's complement values and therefore have two possible representations of zero: positive zero (0x0000) and negative zero (0xffff). In RFC768, UDP over IPv4 exploits this redundancy to repurpose the positive representation of zero (0x0000) to mean "no checksum calculated"; checksums are optional for UDP over IPv4. In RFC2460, checksums are made mandatory for UDP over IPv4. The wording of the RFC is such that the UDP header is mandated to use only the negative representation of zero (0xffff), rather than simply requiring the checksum to be correct but allowing for either representation of zero to be used. In RFC1071, an example algorithm is given for calculating the TCP/IP checksum. This algorithm happens to produce only the positive representation of zero (0x0000); this is an artifact of the way that unsigned arithmetic is used to calculate a signed one's complement sum (and its final negation). A common misconception has developed (exemplified in RFC1624) that this artifact is part of the specification. Many people have assumed that the checksum field should never contain the negative representation of zero (0xffff). A sensible receiver will calculate the checksum over the whole packet and verify that the result is zero (in whichever representation of zero happens to be generated by the receiver's algorithm). Such a receiver will not care which representation of zero happens to be used in the checksum field. However, there are receivers in existence which will verify the received checksum the hard way: by calculating the checksum over the remainder of the packet and comparing the result against the checksum field. If the representation of zero used by the receiver's algorithm does not match the representation of zero used by the transmitter (and so placed in the checksum field), and if the receiver does not explicitly allow for both representations to compare as equal, then the receiver may reject packets with a valid checksum. For UDP, the combined RFCs effectively mandate that we should generate only the negative representation of zero in the checksum field. For IP, TCP and ICMP, the RFCs do not mandate which representation of zero should be used, but the misconceptions which have grown up around RFC1071 and RFC1624 suggest that it would be least surprising to generate only the positive representation of zero in the checksum field. Fix by ensuring that all of our checksum algorithms generate only the positive representation of zero, and explicitly inverting this in the case of transmitted UDP packets. Reported-by: Wissam Shoukair <wissams@mellanox.com> Tested-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-09-10 14:19:16 +02:00
/** Preferred zero checksum value
*
* The checksum is a one's complement value: zero may be
* represented by either positive zero (0x0000) or negative
* zero (0xffff).
*/
uint16_t zero_csum;
/**
* Transport-layer protocol number
*
* This is a constant of the type IP_XXX
*/
uint8_t tcpip_proto;
};
/**
* A network-layer protocol of the TCP/IP stack (eg. IPV4, IPv6, etc)
*/
struct tcpip_net_protocol {
/** Protocol name */
const char *name;
/** Network address family */
sa_family_t sa_family;
/** Fixed header length */
size_t header_len;
/** Network-layer protocol */
struct net_protocol *net_protocol;
/**
* Transmit packet
*
* @v iobuf I/O buffer
* @v tcpip_protocol Transport-layer protocol
* @v st_src Source address, or NULL to use default
* @v st_dest Destination address
* @v netdev Network device (or NULL to route automatically)
* @v trans_csum Transport-layer checksum to complete, or NULL
* @ret rc Return status code
*
* This function takes ownership of the I/O buffer.
*/
int ( * tx ) ( struct io_buffer *iobuf,
struct tcpip_protocol *tcpip_protocol,
struct sockaddr_tcpip *st_src,
struct sockaddr_tcpip *st_dest,
struct net_device *netdev,
uint16_t *trans_csum );
/**
* Determine transmitting network device
*
* @v st_dest Destination address
* @ret netdev Network device, or NULL
*/
struct net_device * ( * netdev ) ( struct sockaddr_tcpip *dest );
};
/** TCP/IP transport-layer protocol table */
#define TCPIP_PROTOCOLS __table ( struct tcpip_protocol, "tcpip_protocols" )
/** Declare a TCP/IP transport-layer protocol */
#define __tcpip_protocol __table_entry ( TCPIP_PROTOCOLS, 01 )
/** TCP/IP network-layer protocol table */
#define TCPIP_NET_PROTOCOLS \
__table ( struct tcpip_net_protocol, "tcpip_net_protocols" )
/** Declare a TCP/IP network-layer protocol */
#define __tcpip_net_protocol __table_entry ( TCPIP_NET_PROTOCOLS, 01 )
extern int tcpip_rx ( struct io_buffer *iobuf, struct net_device *netdev,
uint8_t tcpip_proto, struct sockaddr_tcpip *st_src,
struct sockaddr_tcpip *st_dest, uint16_t pshdr_csum,
struct ip_statistics *stats );
extern int tcpip_tx ( struct io_buffer *iobuf, struct tcpip_protocol *tcpip,
struct sockaddr_tcpip *st_src,
struct sockaddr_tcpip *st_dest,
struct net_device *netdev,
uint16_t *trans_csum );
extern struct tcpip_net_protocol * tcpip_net_protocol ( sa_family_t sa_family );
extern struct net_device * tcpip_netdev ( struct sockaddr_tcpip *st_dest );
extern size_t tcpip_mtu ( struct sockaddr_tcpip *st_dest );
extern uint16_t generic_tcpip_continue_chksum ( uint16_t partial,
const void *data, size_t len );
extern uint16_t tcpip_chksum ( const void *data, size_t len );
extern int tcpip_bind ( struct sockaddr_tcpip *st_local,
int ( * available ) ( int port ) );
/* Use generic_tcpip_continue_chksum() if no architecture-specific
* version is available
*/
#ifndef tcpip_continue_chksum
#define tcpip_continue_chksum generic_tcpip_continue_chksum
#endif
#endif /* _IPXE_TCPIP_H */