alignment exception in ioctl(SIOCGIFCONF) on SPARC/gcc-4.3.0

[strauman]

gcc-4.3.0 generates code which violates the SPARC architecture's alignment requirements. This is due to fancy pointer manipulations which confuse
gcc's optimizer because they violate the C99 standard which
says that pointers to a particular object must always be
properly aligned (C99 draft, 6.3.2.3-7).

The routine

cpukit/libnetworking/net/if.c:ifconf()

scans all interfaces and their addresses
(at different protocol levels) and copies
the addresses out into an array of
'struct ifreq' objects.

The problem is that the entities describing
the interface addresses, namely 'struct sockaddr'
may be larger than their declared size. This
applies, e.g., to the link level address where

sa_len == 54

If this happens, the resulting sequence
of 'struct ifreq' objects is no longer
a real 'array' but a sequence of
possibly mis-aligned objects of different
size.

The copy - algorithm uses a pointer

struct ifreq *ifp

to travel through the destination memory
buffer and may end up having bad alignment.
Simplified, 'ifp' iterates as follows:

while ( space_available(ifp) ) {

/* copy interface name */
memcpy( ifp->ifr_name, src->ifname, 16);

copy_address(ifp, src);

ifp++;
excess = src->sa.sa_len - sizeof(struct sockaddr);
if ( excess > 0 ) {

ifp = (struct ifreq*)((caddr_t)ifp + excess);

}
iterate_source(&src);

}

gcc assumes that 'ifp' always points to
a valid 'struct ifreq' object and hence
is always properly aligned. The 'memcpy'
operation is optimized into a inlined
sequence of four 32-bit load/store operations.

However, if the algorithm ever passes
the 'excess > 0 ' test (and excess is
not a multiple of four) then 'ifp' is
misaligned and the 'memcpy' crashes.

The attached fix makes sure the destination
memory is accessed as a byte stream
w/o specific alignment requirements.

NOTE: the caller, when unpacking the
sequence of ifreqs is likely to encounter
the same problem (see separate bug report
filed for pppd)

[strauman]

Proposed fix

[Joel Sherrill]

ping Eric. Is this safe for 4.10 and head?

[Jeffrey Hill]

see also #2249

[Till Straumann <strauman@…>]

In 237595d86928874024c488d8e101fea4a727e9ab/rtems:

networking: alignment exception in ioctl(SIOCGIFCONF)

Access memory using a byte stream when copying to avoid unaligned
access. close #1401 update #2249

[Till Straumann <strauman@…>]

In 70148eef285bb2ad924d2e25e4b3772bba6eb23c/rtems:

networking: alignment exception in ioctl(SIOCGIFCONF)

Access memory using a byte stream when copying to avoid unaligned
access. update #1401

[Till Straumann <strauman@…>]

In 25e14e3193819f9e418d259e25f162223915114e/rtems:

networking: alignment exception in ioctl(SIOCGIFCONF)

Access memory using a byte stream when copying to avoid unaligned
access. update #1401

[Jeffrey Hill <johill@…>]

In 344856b8adff03b48b2e2e83417e175189ba75b5/rtems:

rpc: misaligned address exception in get_myaddress.c

updates #2249 see #1401

[Jeffrey Hill <johill@…>]

In 2fc3deae2e55fa333368af620fb11413384619a7/rtems:

rpc: misaligned address exception in get_myaddress.c

updates #2249 see #1401

[Jeffrey Hill <johill@…>]

In 49ff36b8d76ad73ee7007ecdf86f355b610ce2b0/rtems:

rpc: misaligned address exception in get_myaddress.c

closes #2249 see #1401