linux-kernel - Re: include/linux/xattr.h: how much userpace visible?

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]

Message-Id: <3E0E2D98-5FEC-403E-831F-2B5BE6A3281A@mac.com>
Date:	Mon, 26 Feb 2007 20:49:00 -0500
From:	Kyle Moffett <mrmacman_g4@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	David Miller <davem@...emloft.net>, a.gruenbacher@...puter.org,
	bunk@...sta.de, linux-kernel@...r.kernel.org, jmorris@...hat.com,
	dwmw2@...radead.org
Subject: Re: include/linux/xattr.h: how much userpace visible?

On Feb 26, 2007, at 19:10:16, H. Peter Anvin wrote:
> Christoph Hellwig wrote:
>> What's the problem of exposing all these APIs unconditionally?   
>> glibcs should either use all information from the linux/ headers  
>> or nothing at all, but not depend on hiding some bits.
>
> It's not always that simple.  In particular, in some files there  
> might be typedefs or structure tags that step on libc's namespace  
> (but are useful to other libcs), but ABI constants that are  
> universally useful.
>
> One way to deal with the particular issue of structure tags which  
> is probably even more useful is:
>
> #if defined(__KERNEL__) || defined(__KERNEL_EXPORT_STRUCTURES)
> # define __kstruct_stat stat
> #endif
>
> struct __kstruct_stat {
> 	/* ...foo... */
> };
>
> ... which lets the libc export it into whatever namespace it wants  
> by #defining __kstruct macros accordingly.

Not a bad idea, but it could use some extra error checking to make  
sure that somebody remembers to "#define __kstruct_foo" before  
"#include <linux/foo.h>" (perhaps indirectly through linux/bar.h).   
Maybe something like this (plays nice with the very-basic unifdef  
parsing too):

#ifdef __KERNEL__
# define __kstruct_stat stat
# define __kstruct_foo foo
# define __kstruct_bar bar
#endif

#ifdef __LINUX_KERNEL_EXPORT
# define __kstruct_stat stat
# define __kstruct_foo foo
# define __kstruct_bar bar
#endif

#ifndef __kstruct_stat
# error "Missing definition of __kstruct_stat, please insert:"
# error "  #define __kstruct_stat <name-for-stat-struct>"
# error "into your C file before '#include <linux/foo.h>'"
#endif
struct __kstruct_stat {
}

Someone who wanted to keep the name __kstruct_stat could of course  
"#define __kstruct_stat __kstruct_stat" easily.

Cheers,
Kyle Moffett

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