Restore and fix 32-bit compat for net.route NET_RT_IFLIST used by getifaddrs(3).

[bdrewery]

Summary

In r207194 32-bit compatibility was added for NET_RT_IFLIST usage by
getifaddrs(3). This was not sufficient for IPv6 addresses though [1].
Using the same SA_SIZE() macro as getifaddrs(3) uses via SA_RLEN()
but with int32_t addresses this issue.

This manifested as empty addresses and corrupt data for IPv6 interfaces
and addresses. This was resulting in node crashing in package build
jails [2].

Much of the compatibility code from r207194 was removed in r263102 when
struct if_data ABI was changed. I have rewritten the needed code to
achieve 32-bit compatibility here but only for NET_RT_IFLIST. The
NET_RT_IFLISTL compatibility continues to work fine due to how
it was designed.

PR: 178881 [1]
PR: 198350 [2]

Test Plan

Running ifconfig(1) on 8.4/9.1/10.0 amd64/i386 chroots. The mediatype
does not show but I believe this is a separate issue with SIOCGIFMEDIA
and unrelated.

Building www/npm. Node now works.

[glebius]

AFAIK, all important software in base is converted to IFLISTL. And all software out of base should use getifaddrs(3). IMHO, efforts should be put into fixing software that relied on utilizing internal API instead of getifaddrs(3).

The patch looks okay.

sys/net/rtsock.c

1692

Extra empty line here.

[bdrewery]

In D2131#6, @glebius wrote:

AFAIK, all important software in base is converted to IFLISTL. And all software out of base should use getifaddrs(3). IMHO, efforts should be put into fixing software that relied on utilizing internal API instead of getifaddrs(3).

The patch looks okay.

8.4 and 9.3 base binaries use IFLIST still.

[kib]

sys/net/rtsock.c

87

I looked at the if.h:struct if_data, and many fields are uint64_t, while you define it as uint32_t. First example is ifi_baudrate.

The only ABI-unsafe types in the struct if_data are time_t and struct timeval.

So this definition looks wrong.

1189

Other code nearby only checks for w != NULL, assuming that w->w_reg is non NULL in this case, look at RTM_IFINFO case in rtsock_msg_buffer(), for instance.

1635

Why is this bzero() needed ? The if_data_copy() does not have the call.

[glebius]

sys/net/rtsock.c

87

Kostik is right. Now, after r263102 the if_data is machine independent. So, what you are trying to achieve with your patch is not COMPAT_FREEBSD32, but COMPAT_FREEBSD32 + COMPAT_FREEBSD-PRE11. With your patch as is you break 32-bit binaries compiled for FreeBSD 11.

[bdrewery]

In D2131#9, @glebius wrote:

Kostik is right. Now, after r263102 the if_data is machine independent. So, what you are trying to achieve with your patch is not COMPAT_FREEBSD32, but COMPAT_FREEBSD32 + COMPAT_FREEBSD-PRE11. With your patch as is you break 32-bit binaries compiled for FreeBSD 11.

I was aware of that actually, but this is only for IFLIST. IFLISTL will continue to work fine. I tested this on 84/91/10 i386. getifaddrs(3) continues to work since 10+ uses IFLISTL.

[bdrewery]

sys/net/rtsock.c

87

It is correct. It is to restore compatibility with if_data from before r207194 for IFLIST only for getifaddr(3) before 10.0 changed it to IFLISTL.

1189

It panics on boot without checking w->w_req. This function is used in many places now and not just sysctls. This was a bug in the patch in the PR that I addressed.

1635

Mostly because you originally did. I suppose in case a field is missed.

[bdrewery]

sys/net/rtsock.c

87

I mean r263102. if_data was changed there which broken ABI (intended). This if_data32 is purposely for older binaries only that use IFLIST.

[bdrewery]

Needs more work. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178881#c9