On Tue, Nov 13, 2007 at 07:59:40PM -0800, Tom Spindler wrote:
> 
> More analysis of how the ioctl is purportedly broken is in that message.
> However, the root cause of such breakage seems to come from the addition
> of some fields to struct ifreq in late May/early June. AFAICT, no other
> programs using SIOCGIFCONF broke due to those changes.

No, you misunderstand: "some fields" weren't added to struct ifreq; rather,
a serious bug in the definition of struct ifreq was fixed: it used the 4.3
style sockaddr (which is of unspecified length, because it's supposed to be
used as a fixed header on a variable-length structure) as static storage.
4.4 introduced sockaddr_storage as a fix for this but somehow this API was
missed (much as a few filesystem syscalls were missed when off_t became
64 bits and required nasty versioning hacks).

This meant that ioctls using this structure (all the IF ioctls) had
truncation and overrun problems, which the compiler errored on when we
started building the system with SSP -- but the bugs were always there.

Unfortunately, the API to any ioctl which used struct ifreq was pretty
much broken by design, because the caller couldn't know how long the
sockaddr embedded in the ifreq actually was (couldn't avoid truncation
of certain types of addresses).  I think Greg is correct when he notes
that there was a sane way for callers to deal with this and a crazy way;
there literally isn't a fix that would accomodate the crazy way, and what
was done to accomodate the "sane" way is about all anyone could think of;
putting everything back how it was isn't an acceptable solution, because
the original bug (forcing callers to make assumptions about the length
of a variadic structure) will recur.

However, one should note that this ioctl appears in no standard and that
we provide a much, much less crappy way for callers to get interface
addresses.  It is probably much less effort to fix each broken caller as
we notice it than to even bother to keep arguing about this.

Thor