netdev - Should TPACKET_ALIGNMENT be defined as 16U rather than just 16, to avoid undefined behavior warnings?

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]

Message-Id: <E6234DB1-C99F-48EC-8D33-3285BD8BD496@alum.mit.edu>
Date:   Sat, 7 Dec 2019 21:29:45 -0800
From:   Guy Harris <guy@...m.mit.edu>
To:     netdev <netdev@...r.kernel.org>
Subject: Should TPACKET_ALIGNMENT be defined as 16U rather than just 16, to
 avoid undefined behavior warnings?

if_packet.h defines:

	#define TPACKET_ALIGNMENT	16
	#define TPACKET_ALIGN(x)	(((x)+TPACKET_ALIGNMENT-1)&~(TPACKET_ALIGNMENT-1))

Some compilers may, if TPACKET_ALIGN() is passed an unsigned value, give a warning that the result of converting ~(TPACKET_ALIGNMENT-1) to an unsigned int is undefined, as ~(TPACKET_ALIGNMENT-1) evaluates to -16 (0xFFFFFFF0), and C doesn't specify the behavior when converting negative values to an unsigned type.

In *practice*, with all the compilers we're likely to see, it just converts it to 4294967280U (0xFFFFFFF0), which is the desired behavior, but it might be cleaner (and produce fewer warnings when compiling code using TPACKET_ALIGN() or any of the macros using it) if TPACKET_ALIGNMENT were defined as 16U, rather than 16, as the entire computation will be done with unsigned integers.

netlink.h was changed to define NLMSG_ALIGNTO as 4U rather than 4, perhaps for the same reason.