答复: Support for userspace TCP/IP stacks

Hi,

Could you please confirm if c-ares affected by the glibc security issue below?
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

Thanks.
________________________________________
发件人: c-ares <c-ares-bounces_at_cool.haxx.se> 代表 Daniel Stenberg <daniel_at_haxx.se>
发送时间: 2016年2月18日 6:25
收件人: c-ares hacking
主题: Re: Support for userspace TCP/IP stacks

On Wed, 17 Feb 2016, Avi Kivity wrote:

Hello!

> 1. make ares_socket_t a struct wrapping either an int or a WIN32 SOCKET
> type; any operations on ares_socket_t (close, sendmsg, etc.) will be
> forwarded to helper functions that extract the fd and call the library
> function; for example
>
> int ares_socket_close(ares_socket_t s)
> {
> return sclose(s.fd);
> }

That sort of wrapping then of course has to be conditionally #ifdef'ed on some
build thing as we don't want to break existing applications.

> 2. add a way to configure function pointers for all the ares_socket_*()
> functions, with defaults calling to the existing code, and change the
> ares_socket_*() functions to call these function pointers.

Since it has to be a build-time option anyway, we can just use #define'd names
for the functions, right? So you'd basically do:

#ifdef MY_MAGIC_TCP_STACK
#define recvfrom(x,y,z) magic_recvfrom(MAGIC_STACK, x, y, z)
#endif

... or did you have something more special in mind?

> Would such a change be acceptable to c-ares?

Yes, we shouldn't have any problems with that.

My advice is to show us your first patch in progress early, so that we can
discuss the specfic approach before you spend a lot of time on a way we
possibly don't agree with!

--
  / daniel.haxx.se