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 17:32:35 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Joseph S. Myers" <joseph@...esourcery.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 05/16/2014 04:47 PM, Joseph S. Myers wrote:
>>
>> 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.
> 

That is not the issue.  The issue is that by fixing the type, the POSIX
committee foolishly fixed the ABI unnecessarily.  There is nothing wrong
with storing this value in a long, of course, but:

a) there is no reason it needs to be as wide as long, on an LP64 ABI an
   int would serve just fine;
b) ABI compatibilility issue, especially since on virtually all ABIs a
   96-bit struct timespec would end up padded to 128 bits anyway;
c) gratuitously different from struct timeval.

>> 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.").

That is a very different thing, though.

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

Given that you already have a long long member of the same structure, it
seems unlikely that adding another long long to this is a problem.

Anyway, this was discussed back in 2011:

https://lkml.org/lkml/2011/8/31/244

	-hpa


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