linux-kernel - Re: [PATCH 04/13] Always expose MAP

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <16169.1442484811@warthog.procyon.org.uk>
Date:	Thu, 17 Sep 2015 11:13:31 +0100
From:	David Howells <dhowells@...hat.com>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	dhowells@...hat.com, "Kirill A. Shutemov" <kirill@...temov.name>,
	Palmer Dabbelt <palmer@...belt.com>, arnd@...db.de,
	viro@...iv.linux.org.uk, ast@...mgrid.com,
	aishchuk@...ux.vnet.ibm.com, aarcange@...hat.com,
	akpm@...ux-foundation.org, luto@...nel.org, acme@...nel.org,
	bhe@...hat.com, 3chas3@...il.com, chris@...kel.net, dave@...1.net,
	dyoung@...hat.com, drysdale@...gle.com, davem@...emloft.net,
	ebiederm@...ssion.com, geoff@...radead.org,
	gregkh@...uxfoundation.org, hpa@...or.com, mingo@...nel.org,
	iulia.manda21@...il.com, plagnioj@...osoft.com, jikos@...nel.org,
	kexec@...ts.infradead.org, linux-api@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-xtensa@...ux-xtensa.org,
	mathieu.desnoyers@...icios.com, jcmvbkbc@...il.com,
	paulmck@...ux.vnet.ibm.com, a.p.zijlstra@...llo.nl,
	tglx@...utronix.de, tomi.valkeinen@...com, vgoyal@...hat.com,
	x86@...nel.org
Subject: Re: [PATCH 04/13] Always expose MAP_UNINITIALIZED to userspace

Josh Triplett <josh@...htriplett.org> wrote:

> > Sure. And 0 is perfectly fine value for the flag. Like with MAP_FILE.
> 
> Rephrasing: the flag should always exist with the correct value.
> Whether the kernel handles it or not, the kernel *headers* shouldn't
> change to match the kernel, not least of which because they don't
> necessarily match the running kernel.  Just like we define the
> prototypes for syscalls that the running kernel may return ENOSYS for.

Josh is correct.

CONFIG_xxx *should* *not* be seen in UAPI headers, except inside #ifdef
__KERNEL__ guards under special circumstances - and #ifdef __KERNEL__ guards
*should* *not* be seen in UAPI headers except under special circumstances.

In terms of such special circumstances, take a peek in
include/uapi/linux/acct.h at struct acct with this:

	/* m68k had no padding here. */
	#if !defined(CONFIG_M68K) || !defined(__KERNEL__)
		__u16		ac_ahz;			/* AHZ */
	#endif

in the middle of it...

Or include/{,uapi/}linux/agpgart.h where it defines two different but
same-named variants of several structs.

Now, some of these - particularly things like the latter - can be fixed by
someone who has the time.

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