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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 May 2014 00:48:26 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Arnd Bergmann <arnd@...db.de>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	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>,
	Chung-Lin Tang <cltang@...esourcery.com>
Subject: Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

On Thu, May 15, 2014 at 10:07:17PM +0100, One Thousand Gnomes wrote:
> True sort of for the kernel (except you've got problems with file system
> compatibility and I believe stuff like NFS and that fact some file
> systems just break).

modern filesystems including NFS don't use anything that corresponds to
a time_t on disk or on the wire, so we'd just need to adjust the few
places the conert time representations.

> > The main advantage that I see with 64-bit time_t is that a lot of user
> > space already works with it, because NetBSD and OpenBSD use this, and
> > all 64-bit Linux systems already work with this without changing the ABI.
> > If we want a POSIX extension to cover a new ABI, this would be the most
> > likely candidate.
> 
> The main advantage IMHO of just using 64bit on 32bit boxes is getting it
> right. I'd go so far as to consider changing userspace time_t to be a
> struct. Yes it'll break lots of code but at least you'll know about it.

I think we're attacking that from the wrong angle.  We'll need to work
with the glibc and other libc folks to what can be implemented as the
library API/ABI and then ensure the kernel provides proper support for
it.

Chaning the size of time_t in the library seems like the only feasible
approach that keeps existing programs compatible.  If we support this
with a time64_, a shifted epoch or structures at the kernel ABI is a
question of balaning what libc needs and what we can use efficiently
internally.

> > As mentioned earlier, between kernel and user space it's probably best
> > to avoid time_t and timeval completely and just use timespec64 or some
> > other safe type, but there has to be a way to port user space that relies
> > on time_t or timespec.
> 
> This I think is bang on. We've already got lots of cases where we can't
> shoehorn useful info into syscalls due to time_t, including stuff like
> exposing accurate stamps in stat(). On an 8MHz 68000 not much happened in
> the same second, on a 32 core x86 it's a bit different.

The stat(64) syscall already has stopped time_t for a long time:

struct stat64 {
	...
	int             st_atime;       /* Time of last access.  */
	unsigned int    st_atime_nsec;
	int             st_mtime;       /* Time of last modification.  */
	unsigned int    st_mtime_nsec;
	int             st_ctime;	/* Time of last status change. */
	unsigned int	st_ctime_nsec;
};

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