* Misaligned IPv6 addresses is SCTP socket options.
@ 2020-07-20 15:50 David Laight
2020-07-21 2:55 ` Marcelo Ricardo Leitner
0 siblings, 1 reply; 3+ messages in thread
From: David Laight @ 2020-07-20 15:50 UTC (permalink / raw)
To: linux-sctp, netdev, Neil Horman
Several of the structures in linux/uapi/linux/sctp.h are
marked __attribute__((packed, aligned(4))).
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.
So the change would have broken binary compatibility
for 32bit applications compiled before the alignment
was added.
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).
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)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Misaligned IPv6 addresses is SCTP socket options.
2020-07-20 15:50 Misaligned IPv6 addresses is SCTP socket options David Laight
@ 2020-07-21 2:55 ` Marcelo Ricardo Leitner
2020-07-21 8:32 ` David Laight
0 siblings, 1 reply; 3+ messages in thread
From: Marcelo Ricardo Leitner @ 2020-07-21 2:55 UTC (permalink / raw)
To: David Laight; +Cc: linux-sctp, netdev, Neil Horman
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)
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: Misaligned IPv6 addresses is SCTP socket options.
2020-07-21 2:55 ` Marcelo Ricardo Leitner
@ 2020-07-21 8:32 ` David Laight
0 siblings, 0 replies; 3+ messages in thread
From: David Laight @ 2020-07-21 8:32 UTC (permalink / raw)
To: 'Marcelo Ricardo Leitner'; +Cc: linux-sctp, netdev, Neil Horman
From: Marcelo Ricardo Leitner
> Sent: 21 July 2020 03:55
>
> 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?
Try arm for starters.
> > 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.
At least on some architectures.
I did wonder if the buffer could be read to 8n+4 aligned memory,
but there are aligned 64bit items elsewhere.
> 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.
Not no mention sctp_assoc_stats....
Which is broken for 32bit binaries on x86 and sparc 64bit kernels.
I think there is (there should be) a kernel type on 64bit
systems that is 8 bytes with the alignment it would have
on the corresponding 32bit architecture.
If nothing else using alignof() on a structure containing
a member of that type will give the 4 or 8 required to fix
the code.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-07-21 8:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-20 15:50 Misaligned IPv6 addresses is SCTP socket options David Laight
2020-07-21 2:55 ` Marcelo Ricardo Leitner
2020-07-21 8:32 ` David Laight
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).