Re: Fifth draft of the Y2038 design document

[Arnd Bergmann <arnd at arndb dot de>]

On Wed, Feb 22, 2017 at 10:16 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Wed, 22 Feb 2017, Albert ARIBAUD wrote:
>> On Wed, 22 Feb 2017 20:55:39 +0000, Joseph Myers
>> <joseph@codesourcery.com> wrote :
>>
>> > On Wed, 22 Feb 2017, Albert ARIBAUD wrote:
>> >
>> > > - this leaves the case of a 64-bit architecture kernel providing a
>> > >   32-bit ABI to 32-bit code. I am not planning on supporting such a
>> > >   scenario.
>> >
>> > There are several such ABIs (ILP32 ABI for a 64-bit architecture) already
>> > supported in glibc, e.g. MIPS n32, and all of them that don't already have
>> > support for 64-bit time_t will need to have it added.
>>
>> I /was/ not planning on supporting such a scenario. :)
>>
>> More seriously: is there already a list of these ABIs?

> That said, I think the following ABIs use 64-bit register size in
> userspace while being ILP32 ABIs.  You'll need to examine the code more
> closely in each case to determine what size time_t is, and to what extent
> if any 64-bit registers are involved in the syscall ABI.  There may be
> other cases where 64-bit registers can in fact be used for what's normally
> considered a 32-bit ABI (e.g. people have done some work on being able to
> use 64-bit registers for 32-bit powerpc code, although the registers are
> 32-bit for all purposes in the function-calling ABI).
>
> AArch64 ILP32 (not yet in glibc)
> MIPS n32
> TileGX32
> x86_64 x32

I don't think the register size matters at all here, any ILP32 ABI running
on a 64-bit kernel is affected the same way. We know that Linux
defines __kernel_time_t as __kernel_long_t, which is the same as
'long' on all ABIs other than x32, so all 32-bit ABIs that can potentially
run on a 64-bit architecture are affected. At the moment this is
arm (both aarch32 and in the future aarch64), mips (both o32 and n32),
parisc, powerpc, s390, sparc, tile and x86 (i386-only, not x32), with risc-v
getting added in the near future, likely before the kernel supports 64-bit
time_t.

Any part of the ABI that is supported on 32-bit kernels must also be
supported on 64-bit kernels in a compatible way (some drivers have
ioctls that don't work in this configuration, but I consider those minor
bugs that we can fix if someone cares enough about a particular
driver). To do this, the 32-bit kernel ABIs will provide a
__kernel_timespec that has a layout matching the 64-bit native
timespec, the question here is how to make the conversion between
the glibc-provided timespec and the kernel-internal timespec as
easy as possible. My goal here is to ensure that any driver that
takes a timespec argument in an ioctl will get it right if it supports
the compat_ioctl at all, and not have a slightly incompatible ABI
between 32-bit and 64-bit kernels running the same user space
binary.

    Arnd