netdev - Re: Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>

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:	Wed, 16 Jan 2013 16:45:11 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	bhutchings@...arflare.com
Cc:	yoshfuji@...ux-ipv6.org, amwang@...hat.com, tmb@...eia.org,
	eblake@...hat.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, libvirt-list@...hat.com,
	tgraf@...g.ch, libc-alpha@...rceware.org, schwab@...e.de,
	carlos@...temhalted.org
Subject: Re: Redefinition of struct in6_addr in <netinet/in.h> and
 <linux/in6.h>

From: Ben Hutchings <bhutchings@...arflare.com>
Date: Wed, 16 Jan 2013 15:47:12 +0000

> On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
>> Cong Wang wrote:
>> > (Cc'ing some glibc developers...)
>> > 
>> > Hello,
>> > 
>> > In glibc source file inet/netinet/in.h and kernel source file
>> > include/uapi/linux/in6.h, both define struct in6_addr, and both are
>> > visible to user applications. Thomas reported a conflict below.
>> > 
>> > So, how can we handle this? /me is wondering why we didn't see this
>> > before.
> [...]
>> This is not a new issue.  In addition to this,
>> netinet/in.h also conflits with linux/in.h.
>> 
>> We might have
>>  #if !defined(__GLIBC__) || !defined(_NETINET_IN_H)
>>  :
>>  #endif
>> around those conflicting definitions in uapi/linux/in{,6}.h.
> 
> This only solves half the problem, as <netinet/in.h> might be included
> after <linux/in.h>.  Also, not all Linux userland uses glibc.

So I've been looking at reasonable ways to fix this.

What would be really nice is if GCC treated multiple identical
definitions of structures the same way it handles multiple identical
definitions of CPP defines.  Which is to silently accept them.

But that's not the case, so we need a different solution.

Another thing to do is to use a new structure for in6_addr in kernel
headers exported to userland.

If we were to make the structure members and accessor macros identical
we could avoid breaking most if not all apps.

However the type name is different so:

	struct in6_addr *p = &kern_struct->member;

wouldn't work so well.  And you couldn't fix up the sources to these
kinds of accesses in a way that work cleanly both before and after
changing the kernel headers.

I'm out of ideas for today.
--
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