32 bit time_t in openembedded

32 bit time_t in openembedded

[Umut Tezduyar Lindskog]

Hi,

Can 32 bits ISA handle year 2038 problem in openembedded?

Our ISA is 32 bits and we are using relatively new kernel with relatively old glibc (2.15). We are using RTC chips which come with a random date/time initialized. We started seeing boot problems in systemd if the random value of RTC is newer than 2038.

https://github.com/systemd/systemd/issues/1143

Upstream systemd’s answer is pretty much using 64 bits time_t structure but this is relatively expensive on 32 bits ISA.

I am wondering what the bit length of time_t structure in openembedded for 32 bits ISAs.

In other words, can your product handle following:

$> date '2038-01-19 03:14’ && hwclock -w (#Wait 7 seconds to see if systemd gets stuck)

NOTE: Don’t forget to revert your date back. Otherwise, your product won’t boot with systemd.

Umut

Re: 32 bit time_t in openembedded

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On 8 September 2015 at 12:44, Umut Tezduyar Lindskog <umut.tezduyar@axis.com
> wrote:

> Upstream systemd’s answer is pretty much using 64 bits time_t structure
> but this is relatively expensive on 32 bits ISA.
>

What problem are you trying to solve here - the general problem of "I want
my hardware to work after 2038" or "my RTC is stupid"?  For the former
you'll potentially be writing a new ABI to introduce a 64-bit time_t (then
updating the kernel, libc, toolchain...), for the latter can't you have
some kernel code that clamps the random times on initialisation to be <2038?

Ross

[-- Attachment #2: Type: text/html, Size: 1021 bytes --]

Re: 32 bit time_t in openembedded

[Umut Tezduyar Lindskog]

Hi Ross,

What I am more after is trying to convince upstream systemd that this might be a potential problem within the embedded world.

Considering that date might get set by a malicious ntp server. In that case user space stops booting for us and I guess my understanding is same thing will happen for openembedded stack too. Isn’t this a concern to anyone?

Umut


> On Sep 8, 2015, at 2:04 PM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> 
> On 8 September 2015 at 12:44, Umut Tezduyar Lindskog <umut.tezduyar@axis.com> wrote:
> Upstream systemd’s answer is pretty much using 64 bits time_t structure but this is relatively expensive on 32 bits ISA.
> 
> What problem are you trying to solve here - the general problem of "I want my hardware to work after 2038" or "my RTC is stupid"?  For the former you'll potentially be writing a new ABI to introduce a 64-bit time_t (then updating the kernel, libc, toolchain...), for the latter can't you have some kernel code that clamps the random times on initialisation to be <2038?
> 
> Ross

Re: 32 bit time_t in openembedded

[Phil Blundell]

On Tue, 2015-09-08 at 13:44 +0200, Umut Tezduyar Lindskog wrote:
> Can 32 bits ISA handle year 2038 problem in openembedded?

Not generically.  But this is not an OE-level problem; the issue is more
that the underlying libraries and kernel ABIs are not currently
Y2038-safe.  Fixing this is not really within the scope of OE and is
more a matter for the respective upstream maintainers to deal with.

See for example some previous discussion of the linux kernel
implications at http://lwn.net/Articles/643407/

>Our ISA is 32 bits and we are using relatively new kernel with
>relatively old glibc (2.15). We are using RTC chips which come with a
>random date/time initialized. We started seeing boot problems in
>systemd if the random value of RTC is newer than 2038.

If this is all you're concerned about and you don't seriously expect
your product to be still in use in 2038 then you could add a sanity
check at bootup to reset the clock to some reasonable default if the
value in the RTC is either known to be in the past or is implausibly far
in the future.  

If you do need full Y2038 support (which wouldn't be totally
unreasonable, given that the end of the epoch is now less than 25 years
away and at least some of us will probably live long enough to see it!)
then you would need to do some more substantial development work and you
should probably contact linux-kernel and/or libc-alpha in the first
instance.  Or update to a natively 64-bit system.

p.

Re: 32 bit time_t in openembedded

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]


> On Sep 8, 2015, at 5:18 AM, Phil Blundell <pb@pbcl.net> wrote:
> 
> On Tue, 2015-09-08 at 13:44 +0200, Umut Tezduyar Lindskog wrote:
>> Can 32 bits ISA handle year 2038 problem in openembedded?
> 
> Not generically.  But this is not an OE-level problem; the issue is more
> that the underlying libraries and kernel ABIs are not currently
> Y2038-safe.  Fixing this is not really within the scope of OE and is
> more a matter for the respective upstream maintainers to deal with.
> 
> See for example some previous discussion of the linux kernel
> implications at http://lwn.net/Articles/643407/
> 
>> Our ISA is 32 bits and we are using relatively new kernel with
>> relatively old glibc (2.15). We are using RTC chips which come with a
>> random date/time initialized. We started seeing boot problems in
>> systemd if the random value of RTC is newer than 2038.
> 
> If this is all you're concerned about and you don't seriously expect
> your product to be still in use in 2038 then you could add a sanity
> check at bootup to reset the clock to some reasonable default if the
> value in the RTC is either known to be in the past or is implausibly far
> in the future.
> 
> If you do need full Y2038 support (which wouldn't be totally
> unreasonable, given that the end of the epoch is now less than 25 years
> away and at least some of us will probably live long enough to see it!)
> then you would need to do some more substantial development work and you
> should probably contact linux-kernel and/or libc-alpha in the first
> instance.  Or update to a natively 64-bit system.
> 

there might be a possibility of writing a compatibility handling of 32bit time_t and switch to using
64bit time_t even on 32bit systems much like netbsd or openbsd. There are patches floating around for kernel
try them out.

> p.
> 
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]