linux-kernel - Re: [rfc] headers_check cleanups break the whole world

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:	Tue, 24 Feb 2009 22:24:37 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Kyle McMartin <kyle@...radead.org>
CC:	mingo@...hat.com, dwmw2@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [rfc] headers_check cleanups break the whole world

Kyle McMartin wrote:
> 
> The reason for this is you cannot intermix glibc header <sys/*.h>
> includes with <linux/*.h> includes for most things without defining the
> __KERNEL_STRICT_NAMES guard. If you fail to define this, you end up
> with multiple definitions of things like dev_t.
> 
> Software was able to get by, because things that used the headers, dvb for
> example were not getting <linux/types.h> into the include chain, because
> they were using <asm/types.h> directly.
> 
> I propose we invert that logic, so the presumable libc that makes use of
> the <linux/types.h> header can just define that it wants these types.
> (test __KERNEL__ as well so the kernel doesn't need a pointless
> #define.)
> 

The Right Thing[TM] here is to change the exported headers so that
*only* the __kernel* names are exported, and then remove the
non-__KERNEL_STRICT_NAMES version of <linux/types.h>.  The *only* libc
for which non-__KERNEL_STRICT_NAMES ever made sense was for the
long-since-obsolete libc5.

This, by the way, is not frivolous work.  The work that has been done in
this area already has smoked out a number of bugs where exported headers
were using user space types, which meant they were using the *WRONG
TYPES* on glibc.  Completely.

> If this isn't tenable, how about moving the {,__}[su]{8,16,32,64}
> integer types into their own header, so we can avoid this mess ever
> occuring in the future. I'm sure the janitors can have a field day with
> that... :)
> 
> That said, who exactly is the userspace consumer for those
> 	typedef __kernel_dev_t	dev_t;
> defines? Can we just include them all in #ifdef __KERNEL__? 

That is exactly what we should do.

For what it's worth, not even klibc uses these types.

	-hpa	

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/