Y2038 - best way forward in Debian?

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Y2038 - best way forward in Debian?

Steve McIntyre
Hey folks,

Apologies - I should have sent this mail quite a while back. :-/

Arnd Bergmann (in CC) has been helping to drive a lot of work to solve
the 2038 problem in the Linux world. I've spoken about this before,
e.g. at DebConf17. He's been pushing a lot of updates throughout the
Linux kernel, and has also been analysing code elsewhere. He's very
interested in how to update complete systems like Debian too, and we
spoke about this some time ago.

The kernel is *basically* fixed now. Internally, data structures
should now be safe. There are a small number places where 32-bit time
is still a thing, but it's in hand. A number of syscalls, ioctls,
etc. have needed updates for the user-kernel interface level. glibc is
the place that needs to care about most of this.

The glibc folks have taken an interesting approach.

 * 64-bit ABIs/architectures are already using 64-bit time_t
   throughout. The design is sane and so we should already be mostly
   safe here, modulo silly code bugs (we'll always have those!)

 * 32-bit ABIs/arches are more awkward. glibc will continue *by
   default* to use 32-bit time_t to keep compatibility with existing
   code. This will *not* be safe as we approach 2038.

 * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
   upwards, but this will of course affect the ABI. Embedded uses of
   time_t in libraries will change size, etc. This *will* be safe for
   2038.

So, we're all fine? Not so much: for our 32-bit Debian arches, we will
need to basically rebuild the world to be 2038-safe. When we had to do
something like this in the past, to deal with the libc5->libc6
transition, we had an SONAME change in libc to work with. We decided
to append the "g" tag to the names of our library binary packages to
signal that a library was built against libc6. We can still see some
of the effects of this in the archive, many years later
(e.g. zlib1g). The problem now is that we will *not* have an soname
change here to help identify code compatibility on the 32-bit front.

Arnd scanned the library packages in the Debian archive and identified
that about one third of our library packages would need rebuilding
(and tracking) to make a (recursive) transition. We can see two
different possible routes to follow:

 A Follow a similar path to last time (rename library packages). This
   will allow us to do partial upgrades, but the cost is that a vast
   number of packages will need work to make this happen,
   *potentially* building library packages twice to allow us to
   continue both 32-bit and 64-bit time_t support forwards for a
   while. This effort will be *needed* only for the sake of our 32-bit
   ports, but would affect *everybody*.

 *** OR ***

 B Decide which 32-bit ports we expect to care about by 2038, and
   re-bootstrap new versions of those ports *with different
   names*. This would allow most of our developers to ignore the
   problem here (as 64-bit arches are not affected) and let a smaller
   number of people re-bootstrap with new ABIs with 64-bit time_t
   embedded. There are some downsides here:

   * we would end up with two versions of some ports for a short time
     - probably one release of overlap

   * users would *not* be able to simply upgrade from one to the
     other, due to lack of binary compatibility

   We *would* be able to run old and new ABIs on top of the same (new
   enough) kernel (e.g. for buildds), so a lump of this would just be
   simply building the new world and filing bugs where needed.

   We'd need to decide exactly which of our 32-bit ports we would want
   to do this path with (probably armhf->arhmft?, maybe
   armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
   continuity, we will most likely *not* end up with a different
   visible ABI via the triplet and the runtime linker, so old/new
   multi-arch will be impossible.

So, which way should we go? My own personal gut feel matches Arnd's,
which would be route B. Some of us already have fair experience with
bootstrapping new arches, and we could almost just crank the handle
for most of this work.

What do people think here? Which do you think is the better path? Feel
free to point out things you think I may have missed. We should get
started on this soon - the longer we leave it, the more likely it is
that we'll see 2038 bugs biting people.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Ansgar Burchardt-5
On Tue, 2020-02-04 at 13:14 +0000, Steve McIntyre wrote:
> What do people think here? Which do you think is the better path? Feel
> free to point out things you think I may have missed. We should get
> started on this soon - the longer we leave it, the more likely it is
> that we'll see 2038 bugs biting people.

At least for i386, I expect it to be used mostly for legacy
applications (and legacy installations).  So breaking ABI by switching
to a "new" architecture or by just changing major libraries like libc6
probably diminishes its value so much that there would no longer be any
use for it: one could just switch to amd64 instead of i386t.

So maybe just recommend people to move to 64-bit architectures and put
32-bit applications in a time namespace so they believe they are still
in 2001 ;-)  32-bit architectures will probably still be useful in
embedded contexts for a long time and there it might be easier to just
change the ABI, but for a general-purpose distribution we start seeing
more and more problems and I don't really see us supporting them as a
full architecture in 10+ years.

Ansgar

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Stefan Monnier
In reply to this post by Steve McIntyre
>  * 32-bit ABIs/arches are more awkward. glibc will continue *by
>    default* to use 32-bit time_t to keep compatibility with existing
>    code. This will *not* be safe as we approach 2038.
>
>  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
>    upwards, but this will of course affect the ABI. Embedded uses of
>    time_t in libraries will change size, etc. This *will* be safe for
>    2038.

And that's chosen at build time (i.e. when compiling glibc)?
Why not provide different entry points for time-manipulating functions,
so a single build can support both applications using 32bit time and
applications using 64bit time?

E.g.

    struct time32_t ...
    struct time64_t ...

    double difftime32 (time32_t time1, time32_t time0);
    double difftime64 (time64_t time1, time64_t time0);

and in the time.h have

    #if TOO_OLD_TO_LIVE_PAST_2038
    typedef time32_t time_t;
    ...
    #else
    typedef time64_t time_t;
    ...
    #endif


-- Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Marco d'Itri
In reply to this post by Steve McIntyre
On Feb 04, Steve McIntyre <[hidden email]> wrote:

>    We'd need to decide exactly which of our 32-bit ports we would want
>    to do this path with (probably armhf->arhmft?, maybe
>    armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
I agree with Ansgar here: there is no point in rebuilding i386.
The porters for the other architectures who believe that there is value
in such a port should explain why they believe that in ~10 years from
now there will still be NEW 32 bit hardware that will run Debian.

The real questions should be: what is the latest reasonable year to
eventually start these new ports? 2038 is far away, and maybe enough
procrastination will solve this...

--
ciao,
Marco

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Lennart Sorensen
In reply to this post by Stefan Monnier
On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:

> >  * 32-bit ABIs/arches are more awkward. glibc will continue *by
> >    default* to use 32-bit time_t to keep compatibility with existing
> >    code. This will *not* be safe as we approach 2038.
> >
> >  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
> >    upwards, but this will of course affect the ABI. Embedded uses of
> >    time_t in libraries will change size, etc. This *will* be safe for
> >    2038.
>
> And that's chosen at build time (i.e. when compiling glibc)?
> Why not provide different entry points for time-manipulating functions,
> so a single build can support both applications using 32bit time and
> applications using 64bit time?
>
> E.g.
>
>     struct time32_t ...
>     struct time64_t ...
>
>     double difftime32 (time32_t time1, time32_t time0);
>     double difftime64 (time64_t time1, time64_t time0);
>
> and in the time.h have
>
>     #if TOO_OLD_TO_LIVE_PAST_2038
>     typedef time32_t time_t;
>     ...
>     #else
>     typedef time64_t time_t;
>     ...
>     #endif

I agree.  Why should this be any different than 64 bit file support?
Transparent on 64 bit architectures, and 32bit code gets to pick the
one it wants to support at compile time while glibc supports both,
and eventually just about everything switches.  You can even eventually
add warnings when any program calls the 32 bit version of the functions.

--
Len Sorensen

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Guillem Jover
In reply to this post by Steve McIntyre
Hi!

On Tue, 2020-02-04 at 13:14:10 +0000, Steve McIntyre wrote:

> The glibc folks have taken an interesting approach.
>
>  * 64-bit ABIs/architectures are already using 64-bit time_t
>    throughout. The design is sane and so we should already be mostly
>    safe here, modulo silly code bugs (we'll always have those!)
>
>  * 32-bit ABIs/arches are more awkward. glibc will continue *by
>    default* to use 32-bit time_t to keep compatibility with existing
>    code. This will *not* be safe as we approach 2038.
>
>  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
>    upwards, but this will of course affect the ABI. Embedded uses of
>    time_t in libraries will change size, etc. This *will* be safe for
>    2038.

I think there is still work pending in glibc to expose both 32-bit and
64-bit interfaces at the same time? (Currently it seems to be either-or.)

I'd like to use this for example in libbsd, to make a smooth
transition similar to the one made in glibc, w/o needing to bump the
SONAME.

> So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> need to basically rebuild the world to be 2038-safe. When we had to do
> something like this in the past, to deal with the libc5->libc6
> transition, we had an SONAME change in libc to work with. We decided
> to append the "g" tag to the names of our library binary packages to
> signal that a library was built against libc6. We can still see some
> of the effects of this in the archive, many years later
> (e.g. zlib1g). The problem now is that we will *not* have an soname
> change here to help identify code compatibility on the 32-bit front.

Well, I guess such a new (conditinally selectable) name could be
coordinated with glibc upstream? Say bump 32-bit ports to use libc6.1?
(We already have precedent in some ports that do not use the same
prevalent SONAME, such as libc6.1, libc0.1 and libc0.1.) But it would
indeed involve lots of work, with massive amounts of package renames. :/

> Arnd scanned the library packages in the Debian archive and identified
> that about one third of our library packages would need rebuilding
> (and tracking) to make a (recursive) transition. We can see two
> different possible routes to follow:
>
>  A Follow a similar path to last time (rename library packages).

>  *** OR ***

>  B Decide which 32-bit ports we expect to care about by 2038, and
>    re-bootstrap new versions of those ports *with different
>    names*. This would allow most of our developers to ignore the
>    problem here (as 64-bit arches are not affected) and let a smaller
>    number of people re-bootstrap with new ABIs with 64-bit time_t
>    embedded. There are some downsides here:

(If we are going for this, I'd say it might make sense to consider
also enabling LFS, although that might be a dangerous change, see
the lintian tag for the rationale. :)

>    * users would *not* be able to simply upgrade from one to the
>      other, due to lack of binary compatibility

I think this conclusion stems from an incorrect premise. See below.

>    We'd need to decide exactly which of our 32-bit ports we would want
>    to do this path with (probably armhf->arhmft?, maybe
>    armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
>    continuity, we will most likely *not* end up with a different
>    visible ABI via the triplet and the runtime linker, so old/new
>    multi-arch will be impossible.

A new dpkg architecture must use a different triplet, as these are
required to be bijective. See “lpia” for a previous example of this.
(This would then make it possible to cross-grade.)

In addition if we are using a new multiarch triplet, and need to
rebuild the world, are going to be ABI incompatible anyway, we might
as well use a proper multiarch-qualified ld.so pathname that does
not collide with anything.

I also think we have a C option, which would be something like:

  C Do a transition equivalent to the LFS one, by either switching
    libraries opportunistically to 64-bit time_t on their next SONAME
    bumps, or by updating them to provide 64-bit variants of their
    interfaces along their 32-bit ones, as done in glibc. Of course
    the main problem here is that the LFS "transition" is not one we
    should be very proud of, as it's been dragging on for a very long
    time, and it's not even close to be finished…

    <https://lintian.debian.org/tags/binary-file-built-without-LFS-support.html>
    (Hmm there seems to be something borked with lintian.d.o, as the
    general tag numbers seem extremely low. :)

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Ben Hutchings-3
In reply to this post by Lennart Sorensen
On Tue, 2020-02-04 at 11:03 -0500, Lennart Sorensen wrote:

> On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:
> > >  * 32-bit ABIs/arches are more awkward. glibc will continue *by
> > >    default* to use 32-bit time_t to keep compatibility with existing
> > >    code. This will *not* be safe as we approach 2038.
> > >
> > >  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
> > >    upwards, but this will of course affect the ABI. Embedded uses of
> > >    time_t in libraries will change size, etc. This *will* be safe for
> > >    2038.
> >
> > And that's chosen at build time (i.e. when compiling glibc)?
> > Why not provide different entry points for time-manipulating functions,
> > so a single build can support both applications using 32bit time and
> > applications using 64bit time?
If I recall correctly, glibc *will* provide both entry points, so there
is no ABI break.  But the size of time_t (etc.) exposed through libc-
dev is fixed at glibc build time.

You should expect that all proposals have already been made and
discussed on the glibc-alpha mailing list over the past few years.

> > E.g.
> >
> >     struct time32_t ...
> >     struct time64_t ...
> >
> >     double difftime32 (time32_t time1, time32_t time0);
> >     double difftime64 (time64_t time1, time64_t time0);
> >
> > and in the time.h have
> >
> >     #if TOO_OLD_TO_LIVE_PAST_2038
> >     typedef time32_t time_t;
> >     ...
> >     #else
> >     typedef time64_t time_t;
> >     ...
> >     #endif
>
> I agree.  Why should this be any different than 64 bit file support?
> Transparent on 64 bit architectures, and 32bit code gets to pick the
> one it wants to support at compile time while glibc supports both,
> and eventually just about everything switches.  You can even eventually
> add warnings when any program calls the 32 bit version of the functions.
LFS is a great example of how *not* to do it.  23 years on, we still
have open bugs for programs that should opt in but didn't.  Not every
program needs to handle > 2 GiB files, but there are now filesystems
with 64-bit inode numbers and they break every non-LFS program that
calls stat().

Similarly, every program that uses wall-clock time will fail as we
approach 2038, and the failure mode is likely to be even worse than
with LFS as few programs will check for errors from time APIs.

Ben.

--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
                                                          - John Lennon


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Steve Langasek
In reply to this post by Lennart Sorensen
On Tue, Feb 04, 2020 at 11:03:03AM -0500, Lennart Sorensen wrote:
> On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:
> > >  * 32-bit ABIs/arches are more awkward. glibc will continue *by
> > >    default* to use 32-bit time_t to keep compatibility with existing
> > >    code. This will *not* be safe as we approach 2038.
> > >
> > >  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
> > >    upwards, but this will of course affect the ABI. Embedded uses of
> > >    time_t in libraries will change size, etc. This *will* be safe for
> > >    2038.

> > And that's chosen at build time (i.e. when compiling glibc)?
> > Why not provide different entry points for time-manipulating functions,
> > so a single build can support both applications using 32bit time and
> > applications using 64bit time?

> > E.g.

> >     struct time32_t ...
> >     struct time64_t ...

> >     double difftime32 (time32_t time1, time32_t time0);
> >     double difftime64 (time64_t time1, time64_t time0);

> > and in the time.h have

> >     #if TOO_OLD_TO_LIVE_PAST_2038
> >     typedef time32_t time_t;
> >     ...
> >     #else
> >     typedef time64_t time_t;
> >     ...
> >     #endif

> I agree.  Why should this be any different than 64 bit file support?
> Transparent on 64 bit architectures, and 32bit code gets to pick the
> one it wants to support at compile time while glibc supports both,
> and eventually just about everything switches.  You can even eventually
> add warnings when any program calls the 32 bit version of the functions.

In practice, despite LFS_CFLAGS having been a priority for Debian as far
back as 2003, I think it was no more than 5 years ago that I was still
finding libraries in the archive that were incompatible with LFS because
they were leaking 32-bit types into their own ABIs.  I think the lesson to
be learned from 64-bit file support is that this was NOT managed effectively
as a transition.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
[hidden email]                                     [hidden email]

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

YunQiang Su
In reply to this post by Steve McIntyre
Steve McIntyre <[hidden email]> 于2020年2月4日周二 下午9:15写道:

>
> Hey folks,
>
> Apologies - I should have sent this mail quite a while back. :-/
>
> Arnd Bergmann (in CC) has been helping to drive a lot of work to solve
> the 2038 problem in the Linux world. I've spoken about this before,
> e.g. at DebConf17. He's been pushing a lot of updates throughout the
> Linux kernel, and has also been analysing code elsewhere. He's very
> interested in how to update complete systems like Debian too, and we
> spoke about this some time ago.
>
> The kernel is *basically* fixed now. Internally, data structures
> should now be safe. There are a small number places where 32-bit time
> is still a thing, but it's in hand. A number of syscalls, ioctls,
> etc. have needed updates for the user-kernel interface level. glibc is
> the place that needs to care about most of this.
>
> The glibc folks have taken an interesting approach.
>
>  * 64-bit ABIs/architectures are already using 64-bit time_t
>    throughout. The design is sane and so we should already be mostly
>    safe here, modulo silly code bugs (we'll always have those!)
>
>  * 32-bit ABIs/arches are more awkward. glibc will continue *by
>    default* to use 32-bit time_t to keep compatibility with existing
>    code. This will *not* be safe as we approach 2038.
>
>  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
>    upwards, but this will of course affect the ABI. Embedded uses of
>    time_t in libraries will change size, etc. This *will* be safe for
>    2038.
>
> So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> need to basically rebuild the world to be 2038-safe. When we had to do
> something like this in the past, to deal with the libc5->libc6
> transition, we had an SONAME change in libc to work with. We decided
> to append the "g" tag to the names of our library binary packages to
> signal that a library was built against libc6. We can still see some
> of the effects of this in the archive, many years later
> (e.g. zlib1g). The problem now is that we will *not* have an soname
> change here to help identify code compatibility on the 32-bit front.
>
> Arnd scanned the library packages in the Debian archive and identified
> that about one third of our library packages would need rebuilding
> (and tracking) to make a (recursive) transition. We can see two
> different possible routes to follow:
>
>  A Follow a similar path to last time (rename library packages). This
>    will allow us to do partial upgrades, but the cost is that a vast
>    number of packages will need work to make this happen,
>    *potentially* building library packages twice to allow us to
>    continue both 32-bit and 64-bit time_t support forwards for a
>    while. This effort will be *needed* only for the sake of our 32-bit
>    ports, but would affect *everybody*.
>
>  *** OR ***
>
>  B Decide which 32-bit ports we expect to care about by 2038, and
>    re-bootstrap new versions of those ports *with different
>    names*. This would allow most of our developers to ignore the
>    problem here (as 64-bit arches are not affected) and let a smaller
>    number of people re-bootstrap with new ABIs with 64-bit time_t
>    embedded. There are some downsides here:
>
>    * we would end up with two versions of some ports for a short time
>      - probably one release of overlap
>
>    * users would *not* be able to simply upgrade from one to the
>      other, due to lack of binary compatibility
>
>    We *would* be able to run old and new ABIs on top of the same (new
>    enough) kernel (e.g. for buildds), so a lump of this would just be
>    simply building the new world and filing bugs where needed.
>
>    We'd need to decide exactly which of our 32-bit ports we would want
>    to do this path with (probably armhf->arhmft?, maybe
>    armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
>    continuity, we will most likely *not* end up with a different
>    visible ABI via the triplet and the runtime linker, so old/new
>    multi-arch will be impossible.
>
> So, which way should we go? My own personal gut feel matches Arnd's,
> which would be route B. Some of us already have fair experience with
> bootstrapping new arches, and we could almost just crank the handle
> for most of this work.
>

Is there the option C?

Draft:
  1. define time64_t
  2. for data_struct which act as a part of ABI, define a new data_struct64
  3. for function which act as part of ABI, define a new version func64.
  4. patch all packages to use time64_t instead of time_t step by step.
  5. set a time as deadline (2030?), and then treat all packages
haven't finished
      the migration as rc-buggy.

 Since we have enough time, we can patch all packages in that period.

> What do people think here? Which do you think is the better path? Feel
> free to point out things you think I may have missed. We should get
> started on this soon - the longer we leave it, the more likely it is
> that we'll see 2038 bugs biting people.
>
> --
> Steve McIntyre, Cambridge, UK.                                [hidden email]
> "Yes, of course duct tape works in a near-vacuum. Duct tape works
>  anywhere. Duct tape is magic and should be worshipped."
>    -― Andy Weir, "The Martian"
>


--
YunQiang Su

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Sam Hartman-3
In reply to this post by Steve McIntyre
Steve, you're presuming that we would not create a new soname for libc6
on architectures where we want a new time ABI.

That             s not at all obvious to me.
It seems in the same level of drastic as the other options you are
considering.
So taking it off the table without discussion or consideration doesn't
seem like a good call.

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Arnd Bergmann-2
In reply to this post by Guillem Jover
On Tue, Feb 4, 2020 at 4:03 PM Guillem Jover <[hidden email]> wrote:

>
> On Tue, 2020-02-04 at 13:14:10 +0000, Steve McIntyre wrote:
> > The glibc folks have taken an interesting approach.
> >
> >  * 64-bit ABIs/architectures are already using 64-bit time_t
> >    throughout. The design is sane and so we should already be mostly
> >    safe here, modulo silly code bugs (we'll always have those!)
> >
> >  * 32-bit ABIs/arches are more awkward. glibc will continue *by
> >    default* to use 32-bit time_t to keep compatibility with existing
> >    code. This will *not* be safe as we approach 2038.
> >
> >  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
> >    upwards, but this will of course affect the ABI. Embedded uses of
> >    time_t in libraries will change size, etc. This *will* be safe for
> >    2038.
>
> I think there is still work pending in glibc to expose both 32-bit and
> 64-bit interfaces at the same time? (Currently it seems to be either-or.)

Correct. I was hoping this could be part of the next glibc release
(2.32), but if it takes longer than that, it may be necessary to start
the bootstrap with an inofficial patched version to find the bugs
and the rebuild everything against a proper release.

A new development that Steve did not mention is that musl
already has working time64 support in its git snapshots (release
will be soon), and Adelie Linux has a first release candidate
based on that. There is also a list of known issues at
https://wiki.adelielinux.org/wiki/Project:Time64 with things that
were either discover during the time64 bootstrap of Adelie
or that I found using Debian Codesearch. Most of these are
for packages that use low-level system calls directly rather than
going through glibc, either for syscalls that don't have an
abstraction (seccomp, futex, ...) or for implementing a runtime
environment for a language other than C.

> I'd like to use this for example in libbsd, to make a smooth
> transition similar to the one made in glibc, w/o needing to bump the
> SONAME.

This can clearly work for specific libraries, but I fear doing this across
all affected library packages adds so much extra work and time before
completion that there won't be many people left to use it by the time
the work is done.;-)

The problem is that new deployments of 32-bit systems only
become rarer over time, even though armhf is still the most common
platform in embedded deployments today, ahead of arm64.

I expect that out of the armhf systems still running in 2038 (or a
few years earlier, while the problems of future dated timestamps
start to build up), most of them will run software that is already
deployed (and broken) or being build in the next few years with a
chance of being fixed.

> > So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> > need to basically rebuild the world to be 2038-safe. When we had to do
> > something like this in the past, to deal with the libc5->libc6
> > transition, we had an SONAME change in libc to work with. We decided
> > to append the "g" tag to the names of our library binary packages to
> > signal that a library was built against libc6. We can still see some
> > of the effects of this in the archive, many years later
> > (e.g. zlib1g). The problem now is that we will *not* have an soname
> > change here to help identify code compatibility on the 32-bit front.
>
> Well, I guess such a new (conditinally selectable) name could be
> coordinated with glibc upstream? Say bump 32-bit ports to use libc6.1?
> (We already have precedent in some ports that do not use the same
> prevalent SONAME, such as libc6.1, libc0.1 and libc0.1.) But it would
> indeed involve lots of work, with massive amounts of package renames. :/

The glibc developers have expressed in the past that they do not
consider this an ABI break and would continue to provide an extended
but compatible ABI with the same soname.

On the distro scale, I fear the opposite is true as Steve explained.

> >  B Decide which 32-bit ports we expect to care about by 2038, and
> >    re-bootstrap new versions of those ports *with different
> >    names*. This would allow most of our developers to ignore the
> >    problem here (as 64-bit arches are not affected) and let a smaller
> >    number of people re-bootstrap with new ABIs with 64-bit time_t
> >    embedded. There are some downsides here:
>
> (If we are going for this, I'd say it might make sense to consider
> also enabling LFS, although that might be a dangerous change, see
> the lintian tag for the rationale. :)

Absolutely, this is already a done deal, as both musl and glibc do not
allow the combination of 32-bit off_t with 64-bit time_t. In musl,
both are now 64-bit for new binaries anyway, and in glibc setting
a 64-bit time_t implies LFS.

> >    We'd need to decide exactly which of our 32-bit ports we would want
> >    to do this path with (probably armhf->arhmft?, maybe
> >    armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
> >    continuity, we will most likely *not* end up with a different
> >    visible ABI via the triplet and the runtime linker, so old/new
> >    multi-arch will be impossible.

So far, armhf is the only Debian target architecture that I know needs
this, so it seems best to focus the work on that one. Once the porting
work is done and enough bugs are fixed, the other architectures can
decide if they still care. If any new 32-bit architectures (rv32, arc?)
get added, it would probably be sensible to start out with a time64
port. At least rv32 glibc won't support time32 interfaces anyway.

> A new dpkg architecture must use a different triplet, as these are
> required to be bijective. See “lpia” for a previous example of this.
> (This would then make it possible to cross-grade.)
>
> In addition if we are using a new multiarch triplet, and need to
> rebuild the world, are going to be ABI incompatible anyway, we might
> as well use a proper multiarch-qualified ld.so pathname that does
> not collide with anything.

Right, I can see this being an overall win. If there is going to be
a new name for the architecture in dpkg, then using a new
architecture triplet feels like a cleaner solution. The tradeoff
is an increased amount of work for the benefit of multiarch
support that can help ease the transition.

I have no estimate how much extra work is needed to support a
new target triplet, but my feeling is that this is much less than
the work a new soname or even making thousands of libraries
deal with both time32 and time64 interfaces.

       Arnd

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Wouter Verhelst
In reply to this post by Steve McIntyre
On Tue, Feb 04, 2020 at 01:14:10PM +0000, Steve McIntyre wrote:
> So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> need to basically rebuild the world to be 2038-safe. When we had to do
> something like this in the past, to deal with the libc5->libc6
> transition, we had an SONAME change in libc to work with. We decided
> to append the "g" tag to the names of our library binary packages to
> signal that a library was built against libc6. We can still see some
> of the effects of this in the archive, many years later
> (e.g. zlib1g). The problem now is that we will *not* have an soname
> change here to help identify code compatibility on the 32-bit front.

Why not? This seems like the type of problem that SONAMEs are made for.
What am I missing?

--
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Florian Weimer
In reply to this post by Steve McIntyre
* Steve McIntyre:

> The kernel is *basically* fixed now. Internally, data structures
> should now be safe. There are a small number places where 32-bit time
> is still a thing, but it's in hand. A number of syscalls, ioctls,
> etc. have needed updates for the user-kernel interface level.

XFS is the elephant in the room, though.

> glibc is the place that needs to care about most of this.

I'm not so sure.  I really do not want glibc to parse and rewrite
ioctl arguments and return values, or ancillary socket data.

> The glibc folks have taken an interesting approach.
>
>  * 64-bit ABIs/architectures are already using 64-bit time_t
>    throughout. The design is sane and so we should already be mostly
>    safe here, modulo silly code bugs (we'll always have those!)

With the exception of utmp/utmpx, see __WORDSIZE_TIME64_COMPAT32 in
the headers.  Unfortuantely, this also affects on-disk data
structures.

>  * 32-bit ABIs/arches are more awkward. glibc will continue *by
>    default* to use 32-bit time_t to keep compatibility with existing
>    code. This will *not* be safe as we approach 2038.
>
>  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
>    upwards, but this will of course affect the ABI. Embedded uses of
>    time_t in libraries will change size, etc. This *will* be safe for
>    2038.
>
> So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> need to basically rebuild the world to be 2038-safe.

The question is whether anyone wants an i386 port where this has
happened.

My opinion (professional in this case, even) is that i386 users want
compatibility with their binaries from 1998.  Otherwise they would
have rebuilt them for x86-64 by now.  Under this worldview, i386 is
for backwards compatibility with existing software.  Users will want
to run these old programs in a time namespace with shifted time, too.

There is also substantial commercial interest in those old binaries
(which becomes apparent when you break glibc compatibility with them
8-/).

>  B Decide which 32-bit ports we expect to care about by 2038, and
>    re-bootstrap new versions of those ports *with different
>    names*. This would allow most of our developers to ignore the
>    problem here (as 64-bit arches are not affected) and let a smaller
>    number of people re-bootstrap with new ABIs with 64-bit time_t
>    embedded. There are some downsides here:
>
>    * we would end up with two versions of some ports for a short time
>      - probably one release of overlap
>
>    * users would *not* be able to simply upgrade from one to the
>      other, due to lack of binary compatibility
>
>    We *would* be able to run old and new ABIs on top of the same (new
>    enough) kernel (e.g. for buildds), so a lump of this would just be
>    simply building the new world and filing bugs where needed.
>
>    We'd need to decide exactly which of our 32-bit ports we would want
>    to do this path with (probably armhf->arhmft?, maybe
>    armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
>    continuity, we will most likely *not* end up with a different
>    visible ABI via the triplet and the runtime linker, so old/new
>    multi-arch will be impossible.

Yes, it really has to be B for i386 at least.

The other issue is that the Y2038 work has tentacles everywhere.
Porting to new architectures (whether they are 32-bit or 64-bit) will
require additional changes to those applications which make direct
system calls, in some cases even if they do not even use time_t or
struct timespec with those system calls at all.  For example, new
ports will not define __NR_futex, only __NR_futex_time64.

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Florian Weimer
In reply to this post by Sam Hartman-3
* Sam Hartman:

> Steve, you're presuming that we would not create a new soname for libc6
> on architectures where we want a new time ABI.

That seems to be a reasonable assumption because Debian would have to
use a different soname from upstream.  glibc upstream does not seem
likely to change soname for this at this point.

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Stefan Monnier
In reply to this post by Florian Weimer
> My opinion (professional in this case, even) is that i386 users want
> compatibility with their binaries from 1998.

I don't claim to be representative, but at least the above doesn't fit
my case: I use i386 on many of my machines and here are the reasons:

- 2 of those machines use processors that don't support amd64 (a Pentium
  III for one and Core Duo for the other).

- For the other 4, the main reason is probably inertia, and the
  secondary reason is that I've found that I'm more affected by cache
  hit/miss (and swapping) than by speed of in-CPU operations, so i386
  gives me slightly higher performance (in those rare cases where I've
  measured it) because both code and data is more compact.

I suspect that none of my 2 non-amd64 machines will be in use by 2038.
And I see no reason why I'd want to "upgrade" to amd64 on the other
machines, but if that's what it takes to keep them running past 2038,
then that's probably what I'll do.


        Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Florian Weimer
In reply to this post by Ben Hutchings-3
* Ben Hutchings:

> If I recall correctly, glibc *will* provide both entry points, so there
> is no ABI break.  But the size of time_t (etc.) exposed through libc-
> dev is fixed at glibc build time.

Is this a Debian-specific decision?

There has been a proposal upstream not to support 32-bit time_t for
new applications at all, but I don't think we will go in that
direction.

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Ben Hutchings-3
On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
> * Ben Hutchings:
>
> > If I recall correctly, glibc *will* provide both entry points, so there
> > is no ABI break.  But the size of time_t (etc.) exposed through libc-
> > dev is fixed at glibc build time.
>
> Is this a Debian-specific decision?

I though that was the *upstream* decision, but perhaps that's still not
decided after all?

Ben.

> There has been a proposal upstream not to support 32-bit time_t for
> new applications at all, but I don't think we will go in that
> direction.
--
Ben Hutchings
The world is coming to an end. Please log off.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Florian Weimer
* Ben Hutchings:

> On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
>> * Ben Hutchings:
>>
>> > If I recall correctly, glibc *will* provide both entry points, so there
>> > is no ABI break.  But the size of time_t (etc.) exposed through libc-
>> > dev is fixed at glibc build time.
>>
>> Is this a Debian-specific decision?
>
> I though that was the *upstream* decision, but perhaps that's still not
> decided after all?

There's going to be a _TIME_BITS selector, similar to
_FILE_OFFSET_BITS.

There was a proposal to have only one API before, but I think the
agreement was that it wouldn't save much complexity.

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Arnd Bergmann-2
In reply to this post by Florian Weimer
On Fri, Feb 7, 2020 at 10:21 PM Florian Weimer <[hidden email]> wrote:
>
> * Steve McIntyre:
>
> > The kernel is *basically* fixed now. Internally, data structures
> > should now be safe. There are a small number places where 32-bit time
> > is still a thing, but it's in hand. A number of syscalls, ioctls,
> > etc. have needed updates for the user-kernel interface level.
>
> XFS is the elephant in the room, though.

XFS is one of the main concerns for 64-bit kernels, but the patches
are likely to get merged in one of the next releases.

For 32-bit, all the ABI issues need to be solved first to have
a working system at all, so let's get that sorted. Obviously all
problems that 64-bit has also need to be solved on 32-bit.

> > glibc is the place that needs to care about most of this.
>
> I'm not so sure.  I really do not want glibc to parse and rewrite
> ioctl arguments and return values, or ancillary socket data.

For a new distro target, it's easy to mandate a minimum kernel
version that has all the ioctls. Users that are stuck on old kernels
for a particular hardware can keep using the existing armhf user
space until that is discontinued.

> >  * 32-bit ABIs/arches are more awkward. glibc will continue *by
> >    default* to use 32-bit time_t to keep compatibility with existing
> >    code. This will *not* be safe as we approach 2038.
> >
> >  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
> >    upwards, but this will of course affect the ABI. Embedded uses of
> >    time_t in libraries will change size, etc. This *will* be safe for
> >    2038.
> >
> > So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> > need to basically rebuild the world to be 2038-safe.
>
> The question is whether anyone wants an i386 port where this has
> happened.
>
> My opinion (professional in this case, even) is that i386 users want
> compatibility with their binaries from 1998.  Otherwise they would
> have rebuilt them for x86-64 by now.  Under this worldview, i386 is
> for backwards compatibility with existing software.  Users will want
> to run these old programs in a time namespace with shifted time, too.

I agree that changing the i386 port is probably a bad idea at the moment,
let's see how the armhf port turns out and fix all the bugs first, as this
is clearly needed anyway. Once there is a working armhf version with
full time64 user space, there can be a separate discussion about what
to do with the i386 port (phase out i386 before y2038, migrate all of
i386 to time64 quickly, have two separate i386 ports, or something
else).

      Arnd

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Arnd Bergmann
In reply to this post by Florian Weimer
On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer <[hidden email]> wrote:

>
> * Ben Hutchings:
>
> > On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
> >> * Ben Hutchings:
> >>
> >> > If I recall correctly, glibc *will* provide both entry points, so there
> >> > is no ABI break.  But the size of time_t (etc.) exposed through libc-
> >> > dev is fixed at glibc build time.
> >>
> >> Is this a Debian-specific decision?
> >
> > I though that was the *upstream* decision, but perhaps that's still not
> > decided after all?
>
> There's going to be a _TIME_BITS selector, similar to
> _FILE_OFFSET_BITS.
>
> There was a proposal to have only one API before, but I think the
> agreement was that it wouldn't save much complexity.

It should be easy to force the _TIME_BITS selection by patching the
glibc headers in Debian though if we want.

The problem with setting _TIME_BITS=64 only using dpkg-buildflags
but leaving the libc default at 32 bits is that anything that users build
themselves or that ignores the buildflags ends up with a broken ABI
when linking against one of the many libraries that expose time_t
in their ABI.

         Arnd

12