linux-kernel - Re: [PATCH] linux/types.h: always export 64bit aligned defines

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, 29 Jan 2008 20:43:01 +0100 (CET)
From:	Jan Engelhardt <jengelh@...putergmbh.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Mike Frysinger <vapier@...too.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Sam Ravnborg <sam@...nborg.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH] linux/types.h: always export 64bit aligned defines


On Jan 27 2008 21:33, Andrew Morton wrote:
>On Sat, 26 Jan 2008 04:23:21 -0500 Mike Frysinger <vapier@...too.org> wrote:
>
>> Some kernel headers exported to userspace rely on these 64bit
>> aligned defines. However, they are hidden behind
>> __KERNEL_STRICT_NAMES at the moment which means most of the time,
>> they're never actually available.

Wrong way. They are inside #ifndef __KERNEL_STRICT_NAMES, so
they _are_ available to userspace.

>> These these defines dont
>> actually conflict with normal userspace / C library types, there's
>> no reason to hide them behind the __KERNEL_STRICT_NAMES define.
>
>Maybe we shouldn't be using these helper macros in
>exported-to-userspace headers.  Do you know which headers are
>affected?  Did you consider jsut expanding the macros in situ for
>thse cases?

grep aligned_u64 include/linux/netfilter{,ipv4,ipv6}/*.h

iptables uses that, but we can get rid of it if need be.
It just throws up 3 lines anyway, ...

>But I'd have thought that if we're going to do this, we should create a
>standard naming convention for types which the kernel exports to userspace.
>Say, kern_*.
>
>In which case the change becomes:
>
>#define kern_aligned_u64 unsigned long long __attribute__((aligned(8)))
>#define kern_aligned_be64 __be64 __attribute__((aligned(8)))
>#define kern_aligned_le64 __le64 __attribute__((aligned(8)))
>
>
>What thinkest thou?

... so could use __attribute__((aligned(8))) directly for exported
headers, like we currently do for pointers (since there is no
alignedptr_64 or so).

>If _that_ is all sane then we should do it all in a singe header file, say
>kern_types_for_userspace.h.  include/linux/types.h would then do:

<linux/utypes.h> maybe? (not_so_long_filenames_please.h.)

>#include <linux/kern_types_for_userspace.h>
>
>#ifdef __KERNEL__
>#define aligned_u64 kern_aligned_u64
>etc...
>
>(all approximate, you-get-what-I-mean)
>
>Duno if it'd be worth the effort, but it is The Right Thing To Do.
--
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/