Subject: Re: restoring sockaddr_dl size; introducing sockaddr_link
To: None <tech-net@NetBSD.org, current-users@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 08/23/2007 17:20:40
>>> [...], however, a number of people have pointed out to me that it
>>> 3rd-party programs may rely on sockaddr_dl's size remaining the
>> Could you explain this in more detail? [...]
> A third-party program might abuse sockaddr_dl by embedding it into a
> wire format and assuming a fixed length.
Sure. But a third-party program might also assume little-endian; does
this mean that we have to avoid big-endian hardware? No, it means such
software is broken - at least if it's intended to be general-purpose.
Similarly, software that blindly assumes that a sockaddr_dl happens to
match a wire format, even if that format was defined based on what a
sockaddr_dl happened to look like at some point, is similarly broken.
Except for a very few structs defined that way for the purpose, it is
simply _broken_ to assume that a struct looks like anything in
particular when viewed as a chunk of bytes (as when overlaying it onto
a wire octet stream). (The only examples I can think of offhand for
the "very few" are things - like struct ip - that are not really
intended for general-purpose application code.)
> If you recompile the program on NetBSD, then it might not be able to
> speak with a second instance of the program, if that instance was
> compiled with a different/older net/if_dl.h.
Right. This means the application code needs fixing.
I can write code that won't be able to interoperate between sparc and
vax because they use different floating-point formats. Does this mean
we need to have one of them fake the other's floating-point format? No,
it means the application code is broken in that portability respect! I
believe that the brokenness you describe is a bug in the application,
and explosing it this way is doing its author(s) a favour by pointing
up their erroneous assumptions.
I once ran into a wire protocol that depended on the exact layout of
the internal key schedules used by a particular DES library. Does this
mean that another DES library has to use the same key schedules? No,
it means there's a portability bug in the protocol design!
> A hypothetical 3rd-party program that reads/writes AF_LINK sockaddrs
> from/to the kernel, today, and that assumes AF_LINK sockaddrs of
> fixed length, has always been broken. It will remain broken.
> However, a hypothetical 3rd-party program that sends/receives AF_LINK
> sockaddrs of fixed length to/from instances of itself will not break,
> because we will not change the length of sockaddr_dl.
Such code has always been broken and will remain broken; I don't see
why it's a good thing to conceal this brokenness. There's no guarantee
our sockaddr_dl matches anyone else's; indeed, if sdl_index values not
multiples of 257 are used, our sockaddr_dl is not compatible between
arches of different endianness right now. As long ago as 1.4T,
sdl_data was already commented as "can be larger; contains both if name
and ll address". We cannot protect idiot code authors from all the
ways they can be idiots, and I believe it is no favour to them to try.
Do you know of any non-hypothetical examples? I suspect that such code
is rare enough that, quite aside from the principles I outlined above,
it's not unreasonable to not care about it.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B