linux-kernel - Re: [PATCH 00/25] Change time_t and clock

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:	Fri, 16 May 2014 23:47:37 +0000
From:	"Joseph S. Myers" <joseph@...esourcery.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Arnd Bergmann <arnd@...db.de>,
	Chung-Lin Tang <cltang@...esourcery.com>,
	John Stultz <john.stultz@...aro.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Christoph Hellwig <hch@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ley Foon Tan <lftan@...era.com>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	LeyFoon Tan <lftan.linux@...il.com>
Subject: Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

On Sat, 17 May 2014, H. Peter Anvin wrote:

> On 05/15/2014 01:38 PM, Arnd Bergmann wrote:
> > 
> > For practical purposes in the kernel, we may still want to use 64-bit
> > nanoseconds: if we use a 96 bit struct timespec, that would be incompatible
> > with the native type on 64-bit kernels, thus complicating the syscall
> > emulation layer.
> > 
> > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > problematic.
> 
> struct timespec is specified in POSIX as having type "long" for tv_nsec.
>  This, as Linus pointed out, is totally braindamaged.

long is a perfectly reasonable type for this purpose - it's guaranteed to 
have enough precision.  ISO C11 follows POSIX in the definition of struct 
timespec.

> x32 does not follow POSIX (Linus pretty much dictated that), and instead
> does the __kernel_suseconds_t to match the native kernel type.  The
> proposal at some point was to try to push a snseconds_t into POSIX.

If the x32 kernel won't be fixed to treat the high part as padding then 
glibc will need fixing to copy all struct timespec values passed to the 
kernel and clear the padding when copying (really, fixing that bug would 
need such copying anyway unless --enable-kernel is used to allow a fixed 
kernel to be assumed).  In any case, we should not put any more ports into 
glibc with that x32 bug; "long" and an explicit padding field is the way 
to go (and copying / zeroing if the kernel doesn't treat that padding 
field as padding).

Adding snseconds_t to POSIX seems pointless when there is no need for this 
field to store values that can't fit in "long".  Even if it were added, 
good practice would say that implementations should keep using "long" 
whenever possible for compatibility with existing applications (just like 
the ISO C recommendation "The types used for size_t and ptrdiff_t should 
not have an integer conversion rank greater than that of signed long int 
unless the implementation supports objects large enough to make this 
necessary.").

If you were designing from scratch, no doubt a typedef such as snseconds_t 
would be there, but with real-world APIs that have accumulated over time, 
deviating from "long" now is a bad idea.

-- 
Joseph S. Myers
joseph@...esourcery.com
--
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/