netdev - 16-byte extra data, and 16-byte alignment, in the memory-mapped receive code for AF

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>] [day] [month] [year] [list]

Date:   Sat, 14 Jul 2018 18:21:53 -0700
From:   Guy Harris <guy@...m.mit.edu>
To:     netdev <netdev@...r.kernel.org>
Subject: 16-byte extra data, and 16-byte alignment, in the memory-mapped
 receive code for AF_PACKET sockets

tpacket_rcv() does

	if (sk->sk_type == SOCK_DGRAM) {
		macoff = netoff = TPACKET_ALIGN(po->tp_hdrlen) + 16 +
				  po->tp_reserve;
	} else {
		unsigned int maclen = skb_network_offset(skb);
		netoff = TPACKET_ALIGN(po->tp_hdrlen +
				       (maclen < 16 ? 16 : maclen)) +
				       po->tp_reserve;
		if (po->has_vnet_hdr) {
			netoff += sizeof(struct virtio_net_hdr);
			do_vnet = true;
		}
		macoff = netoff - maclen;
	}

1) What is the "+ 16" in the SOCK_DGRAM case?  Is it reserving space for libpcap to put a "Linux cooked mode" header in before the packet data?  If so, that should probably be mentioned in a comment, or a #define should be used.

2) The documentation speaks of putting the raw packet data on a 16-byte boundary.

2a) Is this to avoid the "If the data is not aligned on a 16-Byte boundary, then whenever a store crosses a cache-line boundary there is typically a stall." issue mentioned on https://software.intel.com/en-us/forums/intel-isa-extensions/topic/709279 ?

2b) Does this mean that the argument to the PACKET_RESERVE socket option should be a multiple of 16?  If so, that should probably be mentioned in the packet(7) man page.

3) In the non-SOCK_DGRAM case, why does it use 16 instead of a less-than-16-bytes maclen?