Messages in this thread | | | Date | Wed, 31 Aug 2011 10:09:20 -0700 | From | "H. Peter Anvin" <> | Subject | Re: RFD: x32 ABI system call numbers |
| |
On 08/31/2011 09:46 AM, Linus Torvalds wrote: > On Wed, Aug 31, 2011 at 9:14 AM, Arnd Bergmann <arnd@arndb.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". >
Urk. Someone had the bright idea of defining tv_nsec as "long" in the standard, whereas tv_usec is suseconds_t. F**** brilliant, and more than a little bit stupid.
Logically one could work around it by having "struct timespec" contain a padding member in the endian-appropriate place I guess, and make sure to clear it in the kernel, but it's rather ugly. It might have performance advantages to doing it that way, though.
> 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.
We're trying for it. The things we're trying to avoid is to muck (too much) with the compat layer for the mega-multiplex system calls like ioctl. We can't just use the 64-bit ioctl because ioctl structures generally contain pointers.
-hpa
| |