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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFxfmwfB7jbbrXxa=K7VBYPfAvmu3XOkGrLbB1UFjX1+Ew@mail.gmail.com>
Date:	Wed, 31 Aug 2011 09:46:39 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Christoph Hellwig <hch@...radead.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 Wed, Aug 31, 2011 at 9:14 AM, Arnd Bergmann <arnd@...db.de> 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.

I suspect only sane solution to this (having thought about it some
more) is to just say "POSIX is f*^&ing wrong".

I think everybody agrees that time_t *needs* to be 64-bit. That is
only getting more and more clear the closer we get to 2038. There may
be excuses for it for some random crappy 32-bit embedded platform that
nobody really expects to survive for many more years, but it's simply
not debatable for anything else.

And if time_t is 64-bit, then timespec and timeval practically needs
to have a 64-bit tv_usec/tv_nsec because anything else causes problems
with packing etc. And that's doubly true in a 64-bit environment with
a 32-bit "sub-environment".

POSIX has been wrong before. Sometimes the solution really is to say
"sorry, you wrote that 20 years ago, and things have changed".

> * random broken applications assuming that timespec/timeval has
>  two 'long' members, instead of using the proper header files.

Those applications are already broken.

I just googled for these kinds of issues, and found this text: "A
timeval has two components, both ints".  Does that happen to work
often? Yes. Does it make it any more correct? Hell no. But people
really used to believe that, and it even used to be true. AND THEY GOT
FIXED.

If you assume two 'long' members, you're already incorrect, because
'time_t' is not at all guaranteed to be 'long'. And if you assume that
'tv_nsec' is "long", you may be correct wrt POSIX, but given the
realities I think it's still perfectly valid to say "you're a moron,
and we need to fix it".

Because paper is what we use to wipe after we've used the toilet. At
some point, "reality" just hits a hell of a lot harder than any paper
ever will.

I really think that "x32" should try to aim *VERY* hard at using the
64-bit system calls, and seeing itself as being a "32-bit application
in a 64-bit world".  That's not just true for time_t (which I think
should be 64-bit on anything new that expects to survive for any
amount of time), but in general.

I could well imagine, for example, that you might have x32
applications that wanted to access huge datasets, and then use special
"accessor" functions for that (think "HIGHMEM.SYS" except within the
application). That really says "think of it as a 64-bit process, but
with a short pointer mode for density" to me.

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