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]

Message-ID: <Pine.LNX.4.64.1405151748430.3155@digraph.polyomino.org.uk>
Date:	Thu, 15 May 2014 18:01:37 +0000
From:	"Joseph S. Myers" <joseph@...esourcery.com>
To:	Chung-Lin Tang <cltang@...esourcery.com>
CC:	Arnd Bergmann <arnd@...db.de>,
	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 Thu, 15 May 2014, Chung-Lin Tang wrote:

> > c) glibc may or may not provide a way for applications to use
> >    the extended interfaces without a user space ABI break. My
> >    impression so far is that this is going to be too hard and
> >    it won't be done, but this is for the glibc developers to
> >    determine.
> 
> glibc does version its exported symbols, so provided new/old syscalls
> are both provided, haveing a new version of a routine (using 64-bit
> time_t and new syscall interfaces) and the old compat routine co-exist
> should be possible. Of course, old binaries may still not be saved when
> 2038 arrives.

You could do it with symbol versioning, though my guess would be that it 
would be natural to provide _TIME_BITS like _FILE_OFFSET_BITS (with the 
combination _TIME_BITS=64, _FILE_OFFSET_BITS=32 not being supported at 
all) and then later transition the default.  (Discussion of the 
possibility of moving the default to _FILE_OFFSET_BITS=64 suggested that 
in practice most libraries in distributions where this affects the ABI are 
already built that way, though noone has followed up on that discussion to 
try to reach a consensus that we have enough evidence to change the 
default now.  There are a couple of issues with the way 
_FILE_OFFSET_BITS=64 is implemented that should be avoided in any 
implementation of _TIME_BITS=64: (a) _FILE_OFFSET_BITS=64 maps functions 
to corresponding *64 functions in the user's namespace, when it should use 
reserved-namespace names; (b) it's not a no-op for 64-bit platforms - it 
still remaps function names and types.  So _TIME_BITS=64 should only map 
to reserved-namespace names, and not do any remapping at all on platforms 
where time_t is already 64-bit.)

Obviously 64-bit time_t syscalls would be an appropriately narrow set of 
syscalls like those in the generic ABI (so glibc would implement stat for 
_TIME_BITS=64 using fstatat64_time64 or whatever the syscall is called, 
just as the stat functions for generic ABI architectures are implemented 
with newfstatat / fstatat64 rather than lots of separate syscalls.

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