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: <alpine.DEB.2.02.1405131727480.6261@ionos.tec.linutronix.de>
Date:	Tue, 13 May 2014 17:33:01 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Christoph Hellwig <hch@...radead.org>
cc:	Ley Foon Tan <lftan@...era.com>, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, lftan.linux@...il.com,
	cltang@...esourcery.com, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

On Tue, 13 May 2014, Christoph Hellwig wrote:
> On Tue, May 13, 2014 at 04:57:36PM +0800, Ley Foon Tan wrote:
> > This patchset change default time_t and clock_t to 64 bit in
> > include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures override
> > these define to 32 bit in arch posix_types.h.
> > 
> > There is request to support 64 bit time_t for new architecture [1]. According to the
> 
> I think this is an utterly wrong, and very dangerous approach.  A 64-bit
> time_t is something that will need non-trivial porting effort in
> userland, and introducing it only for new fringe architectures is a
> guaranteed way to create silent breakage.
> 
> If you do care about it make sure the architectures that are heavily
> used support it and userland can properly deal with it first, and only
> then default new architectures to it.

Err, we CANNOT do that. We cannot move ANY 32 bit architecture to
64bit time_t without breaking the world and some more.

All 64bit architectures use 64bit time_t already plus the x32 ABI of x86.

So why would user space explode? It did not explode with x32 and it
would be dumb as hell to have new archs use time_t 32bit when we are
currently twisting our brain around how to solve the y2038
problem. Simply because we can not do the BSD flag day approach and
change it.

User space needs to be audited anyway so there is nothing wrong if we
have a few more architectures aside of x32 using a 64bit time_t on a
32 bit machine.

Thanks,

	tglx




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