This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Y2038] Fifth draft of the Y2038 design document
On Mon, Feb 27, 2017 at 9:06 PM, Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
> 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).
The kernel syscall interface does not always adhere to POSIX, and
when a user calls into the syscalls directly, they should follow the
interface that is documented in the kernel man pages instead.
If we decide to have the kernel interface done the way that Zack
suggested based on the x32 precedent (and Linus before him when the
x32 decision was made[1]), we'd leave it up to any libc implementation
to either use the same timespec definition as the kernel, or use the
POSIX definition and do the zero-pad in the syscall wrapper.
Arnd
[1] https://lkml.org/lkml/2011/8/31/244