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:	Thu, 05 Feb 2009 07:17:41 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Jaswinder Singh Rajput <jaswinder@...nel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>, mingo@...e.hu,
	x86@...nel.org, sam@...nborg.org, jirislaby@...il.com,
	gregkh@...e.de, davem@...emloft.net, xyzzy@...akeasy.org,
	mchehab@...radead.org, jens.axboe@...cle.com,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	Avi Kivity <avi@...hat.com>, netfilter-devel@...r.kernel.org
Subject: Re: [GIT PULL -tip] fix 22 make headers_check - 200901

Arnd Bergmann wrote:
> On Wednesday 04 February 2009, H. Peter Anvin wrote:
>> Actually, if anything we should move the *non* __KERNEL_STRICT_NAMES out
>> of <linux/types.h> into something else, or completely deep-six them.  I
>> don't know of any libc which wants these anymore, and I think they're
>> just residual libc5 cruft.
>>
>> However, if we want <linux/extra_types.h> that's fine with me; but
>> <linux/types.h> really should be clean, which means doing what
>> __KERNEL_STRICT_NAMES does now.
> 
> Right now, we have 15 exported headers [1] that use the non-strict 
> posix types (pid_t, off_t, clock_t, ...) and a set of 106 (!)
> files [2] using non-strict integer types (u_int32_t, uint32_t, u32, ...),
> 76 of those alone in netfilter.
> 

Geez.  The integer types is just a pattern replacement, so those we can
just fix.  The 15 exported headers that use other types may very well be
real bugs -- we have had a fair share of broken ioctl signatures due to
exactly this problem.

> Do you think we should fix up all of them before 2.6.29? I'm worried
> that we might introduce more regressions in the process.
> Also, should we leave netfilter alone, in order to reduce the changes?
> I'm also unsure whether a hack in headers_install would be better than
> changing the headers in the source tree.

I have been advocating for hacking headers_install for a while.  That
takes care of the 106.  The 15 *need* to be audited immediately, because
that is even likely to be actual manifest bugs.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ