Re: Fifth draft of the Y2038 design document

[Arnd Bergmann <arnd at arndb dot de>]

On Wed, Feb 22, 2017 at 9:05 AM, Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
> Hi all,
>
> I have produced a fifth draft of what will eventually become the Y2038
> design document:
>
> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=115
>
> Relative to the previous draft:
>
>  * It makes explicit that the implementation should allow the same
>    application source code to build unchanged whether the default for
>    time size is 32-bit (_TIME_BITS undefined or unequal to 64) or
>    64-bit (_TIME_BITS defined equal to 64).
>
>  * Security issues considerations have been added (thanks to Carlos
>    O'Donnel).
>
>  * Timestamps and IOCTLs sections have been expanded.
>
>  * Implementation examples for types has been added.
>
>  * Implementation examples for APIs has been added.
>
> As always, comments welcome.

I found a few minor inaccuracies:

You have classified sched_rr_get_interval() as y2038-compatible, but
getrusage() as incompatible. I think these are both in one category,
either incompatible or a third category: we pass only intervals
here, so there won't be an overflow but redefining timeval still results
in an incompatible ABI, unless the structures are redefined in terms
of 32-bit types instead of time_t/timeval/timespec.

I've discussed the kernel side for "Y2038-incompatible socket
timestamping" with Deep a while ago, and I think we came to a
new conclusions for what would be the best approach. I'll let her
comment here.

For "Y2038-compatible types", please clarify whether time32_t
and time64_t (and related types) are internal-only types or visible
to applications through header files. I assume they are internal
only, but it is not 100% clear. Related to that, what is the expected
definition of time32_t on architectures that never had a 32-bit time_t,
such as existing 64-bit architectures? Is it left undefined and
all code referring to time32_t compiled conditionally?

In "Y2038-compatible struct timespec", replace "microseconds"
with "nanoseconds. Also, it's worth pointing out the known problems
with the padding:
- on big-endian systems, any code doing a variation of
   "struct timespec ts = { seconds, nanos };" is broken because
  it assigns the nanoseconds to the wrong struct member.
  The example code is nonconforming as neither POSIX nor C11
  require a particular order of the struct members, but I could also
  easily find examples of existing programs doing this. Note that
  NetBSD, OpenBSD and Windows have no padding but do use
  64-bit time_t.
- If the padding is uninitialized, we have to explicitly zero it before
  calling a kernel function that assumes the 64-bit layout. This can
  be done in glibc before calling into the kernel, or at the kernel
  entry (where my last patch set does it), but it is awkward either
  way.
Unfortunately, there doesn't seem to be a good solution here
for either of the two problems. Maybe someone else has more
ideas. Using a pointer type for the padding would at least
cause a compile-time warning for broken code, other solutions
might require GCC extensions or break C11 in another way.

I'll comment on the kernel/glibc incompatibilities section tomorrow,
need to collect my thoughts there some more.

     Arnd