Hi Richard,

On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote:

On Tue, 29 Nov 2022 at 16:45, Stephen Jolley
<sjolley.yp.pm@...> wrote:

We’d welcome a proposal/series on how to move forward with the
Y2038 work for 32 bit platforms.

I have the following proposal:

1. A branch is made where:
a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally.
b. qemu is always started with "-rtc base=2040-01-01", simulating
Y2038 actually occurring.
c. an additional runtime test verifies that both RTC clock and
system clock report 2040.

2. This branch is run through a-full on the autobuilder. Any
uncovered issues are filed as bugs.

3. Once *all* of the bugs are addressed, repeat point 2.

4. Once there are no more open bugs, 1a is merged into master.

Any fatal flaws in the plan?

Others have made some good comments. My thoughts:

* We need to add some runtime tests to oeqa for this (in addition to
the ptests)

* We need to have a 32 bit ptest run on the autobuilder (qemux86
should work, not sure we can make qemuarm fast). Whether this is
manually triggered, not sure. We could have a smaller set of ptests
to run for it?

Y2038 ptests maybe?

Here is the list of integrated tests to ptests:
https://github.com/lmajewski/y2038-tests

* Could we optionally disable some of the glibc 32 bit function calls
to ensure they're not being used?

Could you be more specific here? Would you like to disable some
syscalls?

We don't really want to diverge from
upstream glibc much though.

Could you be more specific here? The glibc now supports the whole set
of syscalls as of 2.34 version?

To enable them one needs to pass -D_TIME_BITS=64 flag when compiling
programs.

This is now the official glibc ABI.

* We need to work out how to communicate this change happened and have
people "buy in" to it.

Ok.

The reason for that is that if someone has
existing binaries, there could be problems using them after the
change.

The binary shall work without issues on glibc 2.34+ and 5.10+ kernel
without issues.

The only problem happens when new binaries with 64 bit time support are
run on glibc or kernel not supporting 64 bit time.

We therefore need to be sure they are aware of it.

Cheers,

Richard

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...

On Wed, 2022-11-30 at 14:36 +0100, Lukasz Majewski wrote:

On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote:

On Tue, 29 Nov 2022 at 16:45, Stephen Jolley
<sjolley.yp.pm@...> wrote:

We’d welcome a proposal/series on how to move forward with the
Y2038 work for 32 bit platforms.

I have the following proposal:

1. A branch is made where:
a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally.
b. qemu is always started with "-rtc base=2040-01-01", simulating
Y2038 actually occurring.
c. an additional runtime test verifies that both RTC clock and
system clock report 2040.

2. This branch is run through a-full on the autobuilder. Any
uncovered issues are filed as bugs.

3. Once *all* of the bugs are addressed, repeat point 2.

4. Once there are no more open bugs, 1a is merged into master.

Any fatal flaws in the plan?

Others have made some good comments. My thoughts:

* We need to add some runtime tests to oeqa for this (in addition to
the ptests)

* We need to have a 32 bit ptest run on the autobuilder (qemux86
should work, not sure we can make qemuarm fast). Whether this is
manually triggered, not sure. We could have a smaller set of ptests
to run for it?

Y2038 ptests maybe?

Here is the list of integrated tests to ptests:
https://github.com/lmajewski/y2038-tests

Perhaps, yes.

* Could we optionally disable some of the glibc 32 bit function calls
to ensure they're not being used?

Could you be more specific here? Would you like to disable some
syscalls?

I'm meaning disabling the 32 bit glibc time functions.

We don't really want to diverge from
upstream glibc much though.

Could you be more specific here? The glibc now supports the whole set
of syscalls as of 2.34 version?

To enable them one needs to pass -D_TIME_BITS=64 flag when compiling
programs.

This is now the official glibc ABI.

Right, but the 32 bit time functions/symbols are still available for
older binaries. My point is that anything using those older functions
is likely in need of attention so for Yocto Project/OE usage,
identifying those would be helpful. If we were to disable them, that
would make such usage very obvious.

The reason for that is that if someone has
existing binaries, there could be problems using them after the
change.

The binary shall work without issues on glibc 2.34+ and 5.10+ kernel
without issues.

Not necessarily. If it were a binary library, compiled with 32 bit
time_t, new binaries using it would use a different sized field.

The only problem happens when new binaries with 64 bit time support are
run on glibc or kernel not supporting 64 bit time.

That is definitely not the only problem. Some of the problems are
unlikely but we do need to consider them.

Cheers,

Richard

On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org <richard.purdie=linuxfoundation.org@...> wrote:

* Could we optionally disable some of the glibc 32 bit function calls
to ensure they're not being used?

Could you be more specific here? Would you like to disable some
syscalls?

I'm meaning disabling the 32 bit glibc time functions.

Some time ago I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian has a nice sanity check where it warns if non-LFS glibc functions are used. I imagine the same logic could be used to check for 32-bit time_t use.

Ross

On 30/11/2022 16:46:17+0000, Ross Burton wrote:

On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org <richard.purdie=linuxfoundation.org@...> wrote:

* Could we optionally disable some of the glibc 32 bit function calls
to ensure they're not being used?

Could you be more specific here? Would you like to disable some
syscalls?

I'm meaning disabling the 32 bit glibc time functions.

Some time ago I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian has a nice sanity check where it warns if non-LFS glibc functions are used. I imagine the same logic could be used to check for 32-bit time_t use.

We can simply disable COMPAT_32BIT_TIME in the kernel config.

Ross

--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote:

On 30/11/2022 16:46:17+0000, Ross Burton wrote:

On 30 Nov 2022, at 14:20, Richard Purdie via lists.yoctoproject.org <richard.purdie=linuxfoundation.org@...> wrote:

* Could we optionally disable some of the glibc 32 bit function calls
to ensure they're not being used?

Could you be more specific here? Would you like to disable some
syscalls?

I'm meaning disabling the 32 bit glibc time functions.

Some time ago I filed
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian
has a nice sanity check where it warns if non-LFS glibc functions
are used. I imagine the same logic could be used to check for 32-
bit time_t use.

That sounds interesting and something we should probably look into for
both issues...

We can simply disable COMPAT_32BIT_TIME in the kernel config.

That would cause runtime issues but not build time linking ones?

Cheers,

Richard

On Wed, Nov 30 2022, Richard Purdie wrote:

On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote:

On 30/11/2022 16:46:17+0000, Ross Burton wrote:

On 30 Nov 2022, at 14:20, Richard Purdie via
lists.yoctoproject.org
<richard.purdie=linuxfoundation.org@...> wrote:

* Could we optionally disable some of the glibc 32 bit function calls
to ensure they're not being used?

Could you be more specific here? Would you like to disable some
syscalls?

I'm meaning disabling the 32 bit glibc time functions.

Some time ago I filed
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian
has a nice sanity check where it warns if non-LFS glibc functions
are used. I imagine the same logic could be used to check for 32-
bit time_t use.

That sounds interesting and something we should probably look into for
both issues...

I have a working sanity checker that checks for any glibc functions
affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64.
The INSANE_SKIP functionality needs some more polish but I'd be happy to
contribute it.

Some libraries use both 32 and 64 bit APIs to glibc and needs exceptions
in the checker.

I have not run any world builds with this checker, I've focused on the
recipes we actually use so far so we could get to a testable system. My
biggest worry at the moment is rust, I know to little to know if it is
an actual problem and how to fix it.

I would like to be part of any "y2038 team" for Yocto.

--
Ola x Nilsson

On Mon, 2022-12-05 at 11:00 +0100, Ola x Nilsson wrote:

On Wed, Nov 30 2022, Richard Purdie wrote:

On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote:

On 30/11/2022 16:46:17+0000, Ross Burton wrote:

On 30 Nov 2022, at 14:20, Richard Purdie via
lists.yoctoproject.org
<richard.purdie=linuxfoundation.org@...> wrote:

* Could we optionally disable some of the glibc 32 bit function calls
to ensure they're not being used?

Could you be more specific here? Would you like to disable some
syscalls?

I'm meaning disabling the 32 bit glibc time functions.

Some time ago I filed
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian
has a nice sanity check where it warns if non-LFS glibc functions
are used. I imagine the same logic could be used to check for 32-
bit time_t use.

That sounds interesting and something we should probably look into for
both issues...

I have a working sanity checker that checks for any glibc functions
affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64.
The INSANE_SKIP functionality needs some more polish but I'd be happy to
contribute it.

Some libraries use both 32 and 64 bit APIs to glibc and needs exceptions
in the checker.

I have not run any world builds with this checker, I've focused on the
recipes we actually use so far so we could get to a testable system. My
biggest worry at the moment is rust, I know to little to know if it is
an actual problem and how to fix it.

I would like to be part of any "y2038 team" for Yocto.

That does sound useful, perhaps sharing it as an RFC patch might be a
good place to start? We might be able to run one of the autobuilder
world targets against it, see how it looks for our core recipes?

Cheers,

Richard

On Mon, Dec 05 2022, Richard Purdie wrote:

On Mon, 2022-12-05 at 11:00 +0100, Ola x Nilsson wrote:

On Wed, Nov 30 2022, Richard Purdie wrote:

On Wed, 2022-11-30 at 17:56 +0100, Alexandre Belloni wrote:

On 30/11/2022 16:46:17+0000, Ross Burton wrote:

On 30 Nov 2022, at 14:20, Richard Purdie via
lists.yoctoproject.org
<richard.purdie=linuxfoundation.org@...> wrote:

* Could we optionally disable some of the glibc 32 bit function calls
to ensure they're not being used?

Could you be more specific here? Would you like to disable some
syscalls?

I'm meaning disabling the 32 bit glibc time functions.

Some time ago I filed
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6803 as Debian
has a nice sanity check where it warns if non-LFS glibc functions
are used. I imagine the same logic could be used to check for 32-
bit time_t use.

That sounds interesting and something we should probably look into for
both issues...

I have a working sanity checker that checks for any glibc functions
affected by -D_FILE_OFFSET_BITS=64 or -D_TIME_BITS=64.
The INSANE_SKIP functionality needs some more polish but I'd be happy to
contribute it.

Some libraries use both 32 and 64 bit APIs to glibc and needs exceptions
in the checker.

I have not run any world builds with this checker, I've focused on the
recipes we actually use so far so we could get to a testable system. My
biggest worry at the moment is rust, I know to little to know if it is
an actual problem and how to fix it.

I would like to be part of any "y2038 team" for Yocto.

That does sound useful, perhaps sharing it as an RFC patch might be a
good place to start? We might be able to run one of the autobuilder
world targets against it, see how it looks for our core recipes?

That works for me. I've started preparing a patch for oe-core.

--
Ola x Nilsson