Re: [Y2038] Fifth draft of the Y2038 design document

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

Hi Arnd,

On Mon, 27 Feb 2017 20:46:30 +0100, Arnd Bergmann <arnd@arndb.de>
wrote :

> On Mon, Feb 27, 2017 at 7:45 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> > On Mon, 27 Feb 2017, Arnd Bergmann wrote:
> >  
> >> kernels, so the kernel will either always ignore the padding (which is
> >> a bit more work for the kernel) or it will always reject nonzero upper bits
> >> of the nanoseconds (as 64-bit kernels do today for native tasks, this
> >> means more work in 32-bit glibc, or using 64-bit nanoseconds as
> >> Zack suggested).  
> >
> > Note that the rejection for native tasks (ones where the userspace "long"
> > type used for tv_nsec is 64-bit) is required.  For example, for utimensat,
> > POSIX requires an EINVAL error if "Either of the times argument structures
> > specified a tv_nsec value that was neither UTIME_NOW nor UTIME_OMIT, and
> > was a value less than zero or greater than or equal to 1000 million.".
> > (There are some cases where glibc deals with such rejection itself, if
> > e.g. it's converting an absolute timeout to a relative timeout in order to
> > pass the latter to the kernel.)  
> 
> Sure, I was not suggesting that this check would be changed for 64-bit
> tasks. Aside from the clear violation of the relevant POSIX definition, that
> would also be a subtle ABI change that could lead to breaking existing
> application code.
> 
> What I meant above is that the kernel would either always treat new
> 32-bit tasks the same way as 64-bit tasks both under native 32-bit kernels
> and emulated on 64-bit kernels and leave the zeroing to user space,
> or we do the extra work I described in the kernel, to make it easier for
> a libc implementation to use 'long tv_nsec' without having to zero-pad
> of copy each timespec, again for both native and compat 32-bit tasks.
>
>        Arnd

Maybe a silly question: We all assume that userland code always goes
through GLIBC to invoke kernel syscalls which handle struct timespecs.

There is the possibility, at least theoretically, that userland invoke
these syscalls directly.

Should we consider this possibility, or do we deem it purely
theoretical?

If we consider that not all userland syscalls are made by GLIBC, then
even if GLIBC checked and cleaned all struct it receives from userland
and passes to the kernel, it seems to me that the kernel still has to
check the struct timespecs it receives because they might not come
from GLIBC and thus, they might not have been cleaned by it.

My feeling is that we should check the struct timespecs in the kernel
systematically, and in GLIBC only when using them in computations (as
opposed to passing them to the kernel).

Cordialement,
Albert ARIBAUD
3ADEV