On Mon, Jul 20, 2020 at 03:50:16PM +0000, David Laight wrote: > Several of the structures in linux/uapi/linux/sctp.h are > marked __attribute__((packed, aligned(4))). I don't think we can change that by now. It's bad, yes, but it's exposed and, well, for a long time (since 2005). > > I believe this was done so that the UAPI structure was the > same on both 32 and 64bit systems. > The 'natural' alignment is that of 'u64' - so would differ > between 32 and 64 bit x86 cpus. > > There are two horrible issues here: > > 1) I believe the natural alignment of u64 is actually 8 > bytes on some 32bit architectures. Not sure which? > So the change would have broken binary compatibility > for 32bit applications compiled before the alignment > was added. If nobody complained in 15 years, that's probably not a problem. ;-) > > 2) Inside the kernel the address of the structure member > is 'blindly' passed through as if it were an aligned > pointer. > For instance I'm pretty sure is can get passed to > inet_addr_is_any() (in net/core/utils.). > Here it gets passed to memcmp(). > gcc will inline the memcmp() and almost certainly use 64bit > accesses. > These will fault on architectures (like sparc64). For 2) here we should fix it by copying the data into a different buffer, or something like that. That is happening on structs sctp_setpeerprim sctp_prim sctp_paddrparams sctp_paddrinfo, right? As they all use the pattern of having a sockaddr_storage after a s32. > > No amount of casting can make gcc 'forget' the alignment > of a structure. > Passing to an external function as 'void *' will - but > even the LTO could track the alignment through. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >
