This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define
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.
(Do we still have to pretend that using bare 'long' for the type of
tv_nsec isn't a defect in the relevant standards?)
zw