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
- From: Florian Weimer <fweimer at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Zack Weinberg <zackw at panix dot com>, Joseph Myers <joseph at codesourcery dot com>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair23 at gmail dot com>
- Date: Wed, 04 Sep 2019 14:34:45 +0200
- Subject: Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define
- References: <20190827173015.24370-1-alistair.francis@wdc.com> <CAKCAbMiYinyQ_Gdcu94rPCm6PNw6hdq+H_dhzeADa89v2z13-A@mail.gmail.com> <alpine.DEB.2.21.1908271926030.31674@digraph.polyomino.org.uk> <20190830133818.GI9017@brightrain.aerifal.cx> <alpine.DEB.2.21.1908301630420.5568@digraph.polyomino.org.uk> <CAKCAbMjHbcM=8MvLd2CXA=EyT_iDanzsATMLuiMC=wtgTqOr+A@mail.gmail.com> <20190830170940.GL9017@brightrain.aerifal.cx> <CAKCAbMjVG9=wPr-U-Hac3R0j_1Ks8ueRe+sBabjROfNnXSQ8JA@mail.gmail.com> <20190830182650.GM9017@brightrain.aerifal.cx>
* 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 <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.
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
padding.
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?
Thanks,
Florian