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:	Sun, 18 May 2014 18:18:16 +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 Sun, 18 May 2014, H. Peter Anvin wrote:

> This potentially requires the kernel to maintain three separate ABIs if
> there is a legacy 32-bit ABI, which is quite frankly idiotic.  You seem

Three ABIs seems reasonable enough to me where appropriate.

> to be thinking of POSIX as something handed down by gods, which it
> isn't... quite frankly they did something stupid here and should fix
> their own mess.

In the real world it's useful to support lots of different standard 
versions, not just some hypothetical future version (I see no evidence of 
anyone thinking there is a POSIX defect actually having raised the issue 
with the Austin Group to see if anyone there agrees a change would be 
useful).  We've only just removed support for _BSD_SOURCE / _SVID_SOURCE 
as defined API levels from glibc; I'd guess it will be about 20 years 
before removing support for POSIX.1-2008/2013 is appropriate (even if the 
next major edition relaxes this requirement).

> As far as glibc is concerned, this would require glibc to intercept each
> ioctl, which is completely infeasible... struct timespec/timeval is
> embedded far too deep everywhere.

Well, maybe the subset of applications passing timespec to ioctls should 
carry the cost of converting from the userspace timespec to the kernel 
timespec, rather than POSIX applications carrying the cost of unnecessary 
incompatibility.  (But an enumeration of the relevant ioctls is needed 
anyway simply to provide new versions of them all for 64-bit time_t.)

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