[ntp:questions] ntpd IPv6 support on Windows?

Danny Mayer mayer at ntp.isc.org
Tue Jan 13 02:52:57 UTC 2009


Terje Mathisen wrote:
> Dave Hart wrote:
>> On Jan 11, 6:04 pm, ma... at ntp.isc.org (Danny Mayer) wrote:
>>> Dave Hart wrote:
>>>> I am not suggesting you to go referencing Wsp* functions willy-nilly
>>>> to avoid some perceived (and insignificant) overhead of using
>>>> published APIs.  I'm suggesting you use the published API names like
>>>> getaddrinfo and let Microsoft's runtime binding implementation do what
>>>> it is designed to do.  That it involves macros to inline functions
>>>> with names like WspiapiGetAddrInfo is an implementation detail
>>>> invisible to everyone not using a symbolic debugger against ntp
>>>> binaries on Windows.
>>> That is not correct. These are not macros. The SPI layer is a layer
>>> between Winsock2 and the base layer and there can be multiple SPI layers
>>> and in fact you can specify the order. All of this gets very tricky and
>>> it's one of the reasons why I don't want to go there. Just because
>>> Microsoft provides something doesn't mean that we should use it.
>> You are mistaken.  I'm getting sick of you speaking without checking
>> on the accuracy of your claims.  Wspiapi.h and the Wspiapi-prefixed
>> inline functions and macros have nothing to do with Winsock's Service
>> Provider Interface (SPI).  Rather, they are part of the pedestrian
>> client application socket API.  Please take a few minutes and read the
>> header file, since you are so stubbornly unwilling to believe the
>> documentation I've referred you to repeatedly.
>>
>> http://pf.itd.nrl.navy.mil/mdp/dox/html/wspiapi_8h-source.html
>>
>> You don't even need to have a set of Windows header files handy, the
>> US Navy has kindly published the entire header file at the URL above.
>> You said "these are not macros."  The source code disagrees:
>>
>> 00027 #define getaddrinfo             WspiapiGetAddrInfo
>>
> 
> Dave, I was inclined to agree with you that these headers do look like 
> what we need, functionality-wise they look spot on, but when I started 
> to read the code I found some ugly stuff, i.e.:
> 
> 00272 __inline
> 00273 int
> 00274 WINAPI
> 00275 WspiapiLookupNode(
> 00276     IN  const char                      *pszNodeName,
> 00277     IN  int                             iSocketType,
> 00278     IN  int                             iProtocol,
> 00279     IN  WORD                            wPort,
> 00280     IN  BOOL                            bAI_CANONNAME,
> 00281     OUT struct addrinfo                 **pptResult)
> 00282 /*++
> [snip]
> 
> 00308     char    szFQDN1[NI_MAXHOST] = "";
> 00309     char    szFQDN2[NI_MAXHOST] = "";
> 00310     char    *pszName            = szFQDN1;
> 00311     char    *pszAlias           = szFQDN2;
> 00312     char    *pszScratch         = NULL;
> 00313     strcpy(pszName, pszNodeName);
> 
> I.e. the _very_ first operation of this function is to enable a stack 
> overflow bug/security hole!
> 
> If you send in a too-long szNodeName, then the strcpy() will overwrite 
> lots of stack values. :-(
> 
> Terje

And line 340-341 makes it clear that it's doing it's own lookups:
// there was a new CNAME, look again.
WspiapiSwap(pszName, pszAlias, pszScratch);

That also means that it is not using the resolvers since CNAME restart
is the job of a resolver and that means that this code cannot make use
of DNSSEC and other security changes being added to DNS.

In addition as Martin mentioned this is compile-time code. We need it to
do the right thing at runtime. We won't be supporting IPv6 on Windows
2000, it's just too difficult to deal with from a support point of view.

Danny



More information about the questions mailing list