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 16:03:38 -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

netdev-owner@...r.kernel.org wrote on 04/01/2013 02:15:48 PM:
Date: Mon, 1 Apr 2013 14:05:37 -0400
> 
> >         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.
> 
> in6_addr, which is what sockaddr_in6 is composed of, is precisely the
> problematic type that we want to avoid to elide the double definition
> error.
> 
> http://www.spinics.net/linux/fedora/libvir/msg70921.html
> 
> It's really not safe to use at the moment.
> 
> We're not creating more instances of this mess, and that decision
> is final.

Dave,

I think we're talking about two different things. I'm suggesting
we should use sockaddrs within the kernel module code as the type for
what is now a v4-only address but would be one of v4 or v6 after
adding v6 support.

Within the kernel module code, without changing any header files,
I'm suggesting we use the existing kernel sockaddr definitions and the
sa_family to know which address type we have, instead of defining
a new type local to vxlan.c with the same purpose and most of the
fields as a sockaddr for that very same kernel-only private data.

An additional comment is that those fields missing in the private type
and present in the sockaddr types are useful in cases that apply
to these destination addresses, too; "vxlan_ip" ought to have all the
fields a sockaddr_in6 or sockaddr_in does and if it did, then it
ought to use sockaddr/sockaddr_in/sockaddr_in6 for this kernel-only data.

My suggestion doesn't apply to anything at user level, or visible
to user level through an include file, kernel or glibc.

                                                        +-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