linux-kernel - Re: RFD: x32 ABI system call numbers

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: <201108311839.52863.arnd@arndb.de>
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/