linux-kernel - 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 14:29:30 -0500
From:	Mike Frysinger <vapier@...too.org>
To:	David Miller <davem@...emloft.net>
Cc:	libc-alpha@...rceware.org, bhutchings@...arflare.com,
	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, schwab@...e.de, carlos@...temhalted.org
Subject: Re: Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>

On Wednesday 16 January 2013 13:57:44 David Miller wrote:
> From: Mike Frysinger <vapier@...too.org>
> > certainly true, but the current expectation is that you don't mix your
> > ABIs. if you're programming with the C library API, then use the C
> > library headers. if you're banging directly on the kernel, then use the
> > kernel headers.  not saying it's a perfect solution, but it works for
> > the vast majority of use cases.
> 
> This isn't how real life works.
> 
> GLIBC itself brings in some of the kernel headers, as do various library
> headers for libraries other than glibc.
> 
> So you can get these conflicting headers included indirectly, and it is
> of no fault of any of the various parties involved.

the headers glibc includes tend to be pretty stand alone specifically so that 
it doesn't matter

> We have to make them work when included at the same time somehow, and
> this is totally unavoidable.

"them" is vague.  saying that every kernel header has to be usable in the same 
compilation unit as every C library header regardless of order is unrealistic 
(at least it is today).  there are cases where they define the same structure 
different because the structure as the C library expects is different from what 
the kernel syscall expects.  you could avoid that on the kernel side by giving 
them all prefixes (like __kernel_), but that didn't seem entirely palpable to 
the kernel folks.  i couldn't even get them to remove crap that breaks non-
glibc C libraries (e.g. uapi/linux/stat.h -- looks like someone inadvertently 
fixed uapi/linux/socket.h finally).

for many networking headers, the C library will provide enums & defines while 
the kernel only provides enums.  including the kernel after the C library one 
leads to parsing errors as the defines expand in the enum and kill it.  like 
linux/in.h and netinet/in.h and IPPROTO_*.
-mike

Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)