Re: [Buildroot] [PATCH] Config.in: introduce BR2_TIME_BITS_64 option for Y2038 compatibility

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

On Wed, 12 Oct 2022 23:50:08 +0200
Thomas Petazzoni via buildroot <buildroot@buildroot.org> wrote:

> Y2038 is now almost only 15 years away, and embedded systems built
> today are potentially going to still be operational in 15 years, and
> even though they are supposed to receive updates by then, we all know
> how things go, and potentially some of these embedded systems will not
> receive any update.
> 
> In 2038, the signed 32-bit representation of time_t used on 32-bit
> architectures will overflow, causing all time-related functions to go
> back in time in a surprising way.
> 
> The Linux kernel has already been modified to support a 64-bit
> representation of time_t on 32-bit architectures, but from a C library
> perspective, the situation varies:
> 
>  - glibc uses this 64-bit time_t representation on 32-bit systems
>    since glibc 2.34, but only if -D_TIME_BITS=64 is
>    specified. Therefore, this commit adds an option to add this flag
>    globally to the build, when glibc is the C library and the
>    architecture is not 64-bit.
> 
>  - musl uses unconditionally a 64-bit time_t representation on 32-bit
>    systems since musl 1.2.0. So there is nothing to do here since
>    Buildroot has been using a musl >= 1.2.0, used since Buildroot
>    2020.05. No Buildroot option is needed here.
> 
>  - uClibc-ng does not support a 64-bit time_t representation on 32-bit
>    systems, so systems using uClibc-ng will not be Y2038 compliant, at
>    least for now. No Buildroot option is needed here.
> 
> It should be noted that being Y2038-compliant will only work if all
> application/library code is correct. For example if an
> application/library stores a timestamp in an "int" instead of using
> the proper time_t type, then the mechanisms described above will not
> fix this, and the application/library will continue to be broken in
> terms of Y2038 support.
> 
> Possible discussions points about this patch:
> 
>  - Should we have an option at all, or should we unconditionally pass
>    -D_TIME_BITS=64, like we have been doing for _FILE_OFFSET_BITS=64
>    for quite some time. The reasoning for having an option is that
>    the mechanism is itself opt-in in glibc, and generally relatively
>    new, so it seemed logical for now to make it optional as well in
>    Buildroot.
> 
>  - Should we show something (a Config.in comment?) in the musl and
>    uClibc-ng case to let the user know that the code is Y2038
>    compliant (musl) or not Y2038 compliant (uClibc-ng). Or should this
>    discussion be part of the Buildroot documentation?
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> ---
>  Config.in           | 16 ++++++++++++++++
>  package/Makefile.in |  3 +++
>  2 files changed, 19 insertions(+)

This was discussed/review during the current hackathon, and in the end
we decided to apply it, so it was pushed to master.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot