Subject: Re: restoring sockaddr_dl size; introducing sockaddr_link
To: None <,>
From: David Young <>
List: tech-net
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);
  if (ifp->hw_addr_len)
    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      Urbana, IL * (217) 278-3933 ext 24