sin_zero

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

sin_zero, or more precisely the need to zero it, has been a
longstanding annoyance to me.  Today I think I have tracked down at
least one part of it and am wondering about people's opinions on it.

I wrote a program that tries to install and remove routes (under
certain conditions which aren't relevant here).  It "worked", in that
the writes to the routing socket succeeded, but the routes didn't get
used for packets.  After spending some time digging, I think I know
why.

The kernel routing table for AF_INET is configured with

        rn_inithead, 32, sizeof(struct sockaddr_in),

meaning that it skips 32 bits from the beginning of the sockaddr (these
being sin_family, sin_len, and sin_port), then uses the rest of it up
to the full struct - including sin_zero.  This meant that when my code
installed routes, it was actually generating a noncontiguous route to
(for example) network 0a0001000475201108cd7940, mask
ffffff0008cd644874756e30, the trailing 8 bytes in each value being
unitialized sin_zero data.  Then, of course, packets being sent to (for
example) 0a0001010000000000000000 would not match.

Just to keep things confusing, when netstat queries and prints this
route, it gets 0a0001000475201108cd7940 mask ffffff0008cd644874756e30
but ignores the trailing 8 bytes, even though they're significant to
the kernel, and prints "10.0.1/24".

I am tempted to simply change the routing table config to

        rn_inithead, 32, 8,

(probably spelling 8 using sizeof and offsetof rather than a literal
constant, probably also changing 32 to an offsetof call like the one
IPv6 uses).

What I'm wondering is, would this break anything?  It seems to me like
a no-downside change, but there's a lot of code I don't truly
understand running around there.  I'm of the opinion that the most
correct thing to do is to change it and then fix anything it breaks,
because that really is the correct configuration.  But for the purposes
at hand here, I'd rather work around the bug in userland than get
involved in debugging of long-standing and widely scattered kernel
issues exposed by such a change.  I could, of course, just change it
and see, but there may be issues like "that would expose random kernel
memory to nonprivileged userland via $THING" which aren't obviously
broken but are clearly undesirable.

Opinions?

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B