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:	Wed, 31 Aug 2011 18:39:52 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"H.J. Lu" <hjl.tools@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Richard Kuo <rkuo@...eaurora.org>,
	Mark Salter <msalter@...hat.com>,
	Jonas Bonn <jonas@...thpole.se>,
	Tobias Klauser <tklauser@...tanz.ch>
Subject: Re: RFD: x32 ABI system call numbers

On Wednesday 31 August 2011, H. Peter Anvin wrote:
> On 08/31/2011 09:14 AM, Arnd Bergmann wrote:

> > * padding in struct timespec when you have a long long tv_sec and
> >   32-bit long tv_nsec. This might cause kernel stack data leakage
> >   in some kernel interfaces when they don't clear the padding.
> 
> Don't to that then.  For what it's worth, I think we currently use the
> same size for both fields.

Ok, good point.

> > * random broken applications assuming that timespec/timeval has
> >   two 'long' members, instead of using the proper header files.
> > 
> > Obviously these are all fixable for any new ABI, but will cause
> > some annoyance.
> > 
> > I've added a few people to Cc who are in various stages of the
> > process to finalize their upstream kernel ports. It's clearly
> > the right decision to have time_t 64-bit eventually, the question
> > is how much work is everyone willing to spend in the short run,
> > and who is going to test it. In particular, openrisc has just
> > been merged, so we should not be changing it any more unless
> > there is a serious problem, but if there is not much legacy user
> > space with the current ABI yet, it may still be worth switching
> > over.
> 
> Either way, all of this applies to x32 even more, sadly.
> 
> The other thing is that we probably need to do is to set a date when we
> redefine legacy 32-bit time_t to be unsigned.  A good time might be some
> time around (time_t)0x60000000 = Thu Jan 14 08:25:36 UTC 2021 if not sooner.

Well, we could chicken out and just use unsigned int for time_t on new
32 bit ABIs, which would buy us time until ~2106 before we need to
convert everything to 64 bit...

Do you see any side-effects of changing time_t to unsigned, besides
file dates outside of the 1970...2038 range? If we end up having to
introduce new syscalls because of some incompatibility, we could just
as well introduce the full set of syscalls using a new time64_t for
32 bit architectures, like we did for uid32_t and loff_t.
The only problem that I can see right now with changing over is that
the 32-on-64 bit emulation changes from sign-extend to zero-extend.

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ