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 09:10:43 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Joseph S. Myers" <joseph@...esourcery.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 05/18/2014 06:46 AM, Joseph S. Myers wrote:
> 
> It's advising against breaking compatibility with existing applications 
> (in that case, C90 applications that assume sizes can be cast to unsigned 
> long for printing, etc.) unless necessary.
> 

Yes, the values in question will not be a problem for that in this case,
so it doesn't apply.

> Rich Felker suggests 
> <https://sourceware.org/bugzilla/show_bug.cgi?id=16438> there are similar 
> security risks from various types in the x32 ABI being wider than size_t.  
> That seems entirely plausible, if unconfirmed; I don't think there's been 
> much effort to look for such issues where applications expect types to be 
> no wider than size_t when there's no use to them being wider than size_t.  
> Most of those choices are valid but may be risky to existing software much 
> as IL32LLP64 can be risky to existing software.

Everything can be risky if done poorly, unfortunately.

> The userspace ABI for struct timespec with 64-bit time_t and 32-bit long 
> should use long tv_nsec in any future ports, with appropriate conversion 
> code in glibc if the kernel interface is different (for ports that started 
> out with 32-bit time_t, conversion code will be needed anyway to convert 
> to the 32-bit structure if the new syscalls are unavailable at runtime and 
> so the old syscalls need to be used, but if the kernel's structure with 
> 64-bit time_t is different from that in userspace then both old and new 
> kernels need conversion code).  Given Rich Felker's bug reports, it seems 
> reasonable to suppose that musl will wish to do this as well as glibc.

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

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.

	-hpa

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

Powered by blists - more mailing lists