This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

* Rich Felker:

> On Fri, Aug 30, 2019 at 01:19:27PM -0400, Zack Weinberg wrote:
>> On Fri, Aug 30, 2019 at 1:09 PM Rich Felker <> 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 <> 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.

I don't see how this clears the padding.  I don't think we can support
any concise syntax for that:

If we give the padding a name, this will not work on big-endian targets

  ts?(struct timespec[]){ts->tv_sec, ts->tv_nsec}:0

because the padding is in the middle, and ts->tv_nsec is copied into the

If we do not give the padding a name, the expression leaves the padding
uninitialized (C11: “Unnamed members of structure objects have
indeterminate value even after initialization.”).

And who should do this?  I think for pselect, glibc has to do it, but
what about ioctls and socket options?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]