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: <5228220.XfC7baN05k@wuerfel>
Date:	Mon, 19 May 2014 19:22:13 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Joseph S. Myers" <joseph@...esourcery.com>
Cc:	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 Monday 19 May 2014 14:46:59 Joseph S. Myers wrote:
> On Mon, 19 May 2014, Arnd Bergmann wrote:
>
> Now, when the motivation is not space reduction but ensuring nothing is 
> there that will break in 2038 (unless it's doing dubious things like 
> storing a time_t value in an int or long in the application - something a 
> reasonably stupid static analysis should be able to detect), you could 
> always identify the (symbol, version) pairs for a given architecture that 
> use 32-bit time_t and develop a tool that checks for binaries using 
> problem symbols.  (Of course, that won't help with ioctls.)  Or put a 
> small patch in the headers to force _TIME_BITS=64 and not allow an 
> override with _TIME_BITS=32.  And if the kernel had a config option to 
> disable all the old interfaces, that would make problem binaries break now 
> rather than in 2038.

I had already thought of the kernel option, that's probably one thing
we will do here, but it won't help if glibc then emulates the interfaces
we remove ;-)

A related question would be how you plan to support future CPU architectures
that never had the 32-bit time_t in the kernel ABI. Would you also want
to provide both 32 and 64 bit time_t to user space on those?

Then again I'm not sure how relevant glibc is to the deeply embedded
distros that would want to run without the backwards compatibility.
I suspect that uClibc, musl and bionic would just offer a compile time
switch without any emulation.

> > > > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > > > problematic.
> > > 
> > > Yes, we have a glibc bug 
> > > <https://sourceware.org/bugzilla/show_bug.cgi?id=16437> about the glibc 
> > > definition (64-bit tv_nsec in x32 userspace to match the kernel's 64-bit 
> > > "long") being nonconforming, but without the kernel treating upper bits as 
> > > padding, fixing glibc requires wrappers that copy the value and clear the 
> > > upper bits.
> > 
> > Ok. There is also work going on to have an x32-like ABI for ARM64, and
> > that will likely have to support big-endian as well, so then it's not
> > just about clearing the padding bits, but also having them in the right
> > place.
> 
> Yes, I see no problem with putting the padding bits in the right place so 
> that when the kernel is passing struct timespec values *to* userspace, it 
> can just fill in the native 64-bit structure and have it automatically be 
> correct when interpreted as a 32-bit structure with padding (which the 
> kernel will have zeroed implicitly) on tv_nsec.

Ok.

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