netdev - Re: [Patch net-next v1 3/4] vxlan: add ipv6 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 1 Apr 2013 14:05:37 -0400
From:	David Stevens <dlstevens@...ibm.com>
To:	David Miller <davem@...emloft.net>
Cc:	amwang@...hat.com, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org, stephen@...workplumber.org
Subject: Re: [Patch net-next v1 3/4] vxlan: add ipv6 support

David Miller <davem@...emloft.net> wrote on 04/01/2013 01:02:23 PM:

> 
> People avoid using sockaddr because it gets defined both in the kernel
> exported userland headers and the native libc ones with no easy
> protection between the two to avoid getting a double definition error.
> 
> Once you start including kernel exported headers for things like these
> network device specific interfaces, you potentially run into that issue.
> 
> Therefore I'd rather the subsystem define their own unique type both
> to avoid this double definition problem and to allow easy extention
> later.

        I guess, but in this case, I'm not saying it's like a sockaddr 
with
device-specific requirements. Rather, I'm saying it's exactly a sockaddr--
it is either a sockaddr_in or a sockaddr_in6 and a family field to say
which.
        As is, any user/kernel include file conflicts (in the "ip" 
command,
presumably) are still present because he's using in6_addr, another 
structure
both in user and kernel space.
        The primary multiple include issue here would be in the "ip" 
command,
presumably, but sockaddrs in particular have to agree between user and
kernel space already and both appear with "ip".
        This patch also has issues due to NOT copying other fields in the
sockaddr_in6 structure (scope_id and port).

        Personally, I don't think it's too difficult to make correct code
using sockaddr/sockaddr_in/sockaddr_in6 here, but even with a new type,
the code within vxlan.c could (and I argue should) use something like:

       union {
               struct sockaddr_in       vip_un_sin;
               struct sockaddr_in6      vip_un_sin6;
               struct sockaddr          vip_un_sa;
       } vip_sun;

#define vip_sa  vip_sun.vip_un_sa
#define vip_sin vip_sun.vip_un_sin
#define vip_sin6        vip_sun.vip_un.sin6

and then code like:
switch (vip->vip_sa.sa_family) {
case AF_INET:
        vip->vip_sin.sin_addr.s_addr = blah blah
        break;
case AF_INET6:
        vip->vip_sin6.sin6_addr = blah blah
        break;
...
}

...or whatever appropriate to the context and family.


                                                        +-DLS

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html