Subject: Re: restoring sockaddr_dl size; introducing sockaddr_link
To: None <tech-net@NetBSD.org, current-users@NetBSD.org>
From: David Young <email@example.com>
Date: 08/23/2007 17:10:07
On Thu, Aug 23, 2007 at 05:20:40PM -0400, der Mouse wrote:
> >>> [...], however, a number of people have pointed out to me that it
> >>> 3rd-party programs may rely on sockaddr_dl's size remaining the
> >>> same.
> >> 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.)
This is an important perspective. It sounds to me like we agree that
if a 3rd-party program depends on an AF_LINK sockaddr of fixed size,
then it is abusing sockaddr_dl. However, enough developers have told me
their concern that changing the size of sockaddr_dl will have unforeseen
consequences on 3rd-party programs, that I feel that I must respond.
And besides, even if 3rd-party software is not written to NetBSD's
standards, our users will not forgive us when it stops working.
> 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.
I have the Quagga sources right before me, and it looks as if Quagga
embeds a sockaddr_dl in a wire-protocol packet. In quagga/lib/zclient.c,
zebra_interface_add_read(), I have found some sockaddr_dl abuse:
stream_get (&ifp->sdl, s, sizeof (ifp->sdl));
ifp->hw_addr_len = stream_getl (s);
stream_get (ifp->hw_addr, s, ifp->hw_addr_len);
#endif /* HAVE_SOCKADDR_DL */
Elsewhere in Quagga, it looks as if someone intended to abuse sockaddr_dl
some more, but they did not finish.
David Young OJC Technologies
firstname.lastname@example.org Urbana, IL * (217) 278-3933 ext 24