Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define

[Rich Felker <dalias at libc dot org>]

On Fri, Aug 30, 2019 at 01:19:27PM -0400, Zack Weinberg wrote:
> On Fri, Aug 30, 2019 at 1:09 PM Rich Felker <dalias@libc.org> wrote:
> > On Fri, Aug 30, 2019 at 01:03:16PM -0400, Zack Weinberg wrote:
> > > On Fri, Aug 30, 2019 at 12:37 PM Joseph Myers <joseph@codesourcery.com> wrote:
> > > > On Fri, 30 Aug 2019, Rich Felker wrote:
> > > > > To clarify, none of the timespec ones "exactly match" -- the suffixed
> > > > > syscalls on 32-bit require filling the padding around tv_nsec, whereas
> > > >
> > > > What do you mean by "require filling the padding"?  I thought the
> > > > conclusion in the kernel was that it dealt with zeroing the padding
> > > ....
> > >
> > > The kernel should always explicitly clear all of the padding in any
> > > structure it writes to user space, anything else risks leaking kernel
> > > data (e.g. the compiler decides it can use a 64-bit load and store to
> > > copy from the kernel's struct timespec to the user space struct
> > > timespec because those high bits are don't-care in the destination
> > > .... oops, the previous allocation had a kernel pointer in that 64-bit
> > > slot and we just exposed the KASLR base).
> >
> > The issue is the other direction, when timespecs are passed to the
> > kernel (usually for read-only access), e.g. providing a timeout.
> 
> Sorry, I misunderstood which direction you were talking about.
> 
> I think ignoring the padding bits has to be the kernel's
> responsibility, because the C library can't assume that these pointers
> refer to writable storage, nor can it assume that it is safe (or
> acceptably efficient) to copy the data structure.

You don't patch them up. You copy them. E.g. instead of passing ts,
pass ts?(struct timespec[]){*ts}:0.

> (Do we still have to pretend that using bare 'long' for the type of
> tv_nsec isn't a defect in the relevant standards?)

It's not a defect. There's no reason for a special typedef for this
field because long can necessarily represent the range of nanoseconds,
[0,999999999].

Rich