[Ksummit-discuss] Leap second handling

[Ksummit-discuss] Leap second handling

[David Howells]

I know it's a bit late for the KS, but should we alter the interpretation of
the time-as-seconds-since-1970 in the kernel to include leap seconds?

The reason I ask is that we have to deal with X.509 certificates in the kernel,
and the certificate can have dates encoded using GeneralizedTime ASN.1 objects.
These are formatted as per ISO 8601.  ISO 8601 encodes leap seconds as hh:mm:60
- so it's possible that I can see this in cert I have to deal with, and as such
I must permit it.  I turn the date and time components into a time64_t with
mktime64() - but that doesn't know about leap seconds, however.

So the question is how to deal with it.  I can see three obvious ways:

 (1) Treat it the same as hh:mm:59.

 (2) Treat it the same as hh:mm+1:00, rolling over the carry through to the
     year if necessary.

 (3) Assign specific time_t values to leap seconds in mktime64().  There's a
     table of them here:

	https://en.wikipedia.org/wiki/Leap_second

     It wouldn't be hard to do within just the kernel, but this would put the
     kernel at odds with userspace to the tune of nearly half a minute at the
     current time.  It might be sufficient to just fix the libc's in userspace
     - but you can bet there's someone somewhere who checks that seconds
     doesn't exceed 59.

     The kernel would also need to tell libc whether or not the time value it
     gets includes leap seconds.

Any thoughts?

David

Re: [Ksummit-discuss] Leap second handling

[Arnd Bergmann]

On Tuesday 15 December 2015 11:33:58 David Howells wrote:
> I know it's a bit late for the KS, but should we alter the interpretation of
> the time-as-seconds-since-1970 in the kernel to include leap seconds?
> 
> The reason I ask is that we have to deal with X.509 certificates in the kernel,
> and the certificate can have dates encoded using GeneralizedTime ASN.1 objects.
> These are formatted as per ISO 8601.  ISO 8601 encodes leap seconds as hh:mm:60
> - so it's possible that I can see this in cert I have to deal with, and as such
> I must permit it.  I turn the date and time components into a time64_t with
> mktime64() - but that doesn't know about leap seconds, however.

Adding John Stultz to Cc explicitly, he probably knows best about those things.

> So the question is how to deal with it.  I can see three obvious ways:
> 
>  (1) Treat it the same as hh:mm:59.
> 
>  (2) Treat it the same as hh:mm+1:00, rolling over the carry through to the
>      year if necessary.
> 
>  (3) Assign specific time_t values to leap seconds in mktime64().  There's a
>      table of them here:
> 
> 	https://en.wikipedia.org/wiki/Leap_second
> 
>      It wouldn't be hard to do within just the kernel, but this would put the
>      kernel at odds with userspace to the tune of nearly half a minute at the
>      current time.  It might be sufficient to just fix the libc's in userspace
>      - but you can bet there's someone somewhere who checks that seconds
>      doesn't exceed 59.
> 
>      The kernel would also need to tell libc whether or not the time value it
>      gets includes leap seconds.
> 
> Any thoughts?

The kernel supports CLOCK_TAI as a timebase. While I think some operating systems
use this as the default clock, we don't do that, and I assume we don't want
to change this.

ktime_get_clocktai() will return the time in this format, and the timekeeper
stores the offset between boottime and TAI internally, and updates it whenever
a leap second happens, so if you set a timer in CLOCK_TAI, it will expire at
the right moment.

What I think we don't do at all in the kernel is to keep track of past (or
even future) leap seconds, so if you need to encode a date in the past,
the kernel has no idea what the difference between UTC and TAI was at the
time, and if you encode a time in the future, you don't know if we will
insert a leap second before you get to that time. I think these are the
harder questions to solve first if you want to handle the X.509 certificates
right, before we get to the question of what happens for dates *on* the
leap second.

	Arnd

Re: [Ksummit-discuss] Leap second handling

[Alexandre Belloni]

Hi,

On 15/12/2015 at 13:12:03 +0100, Arnd Bergmann wrote :
> > So the question is how to deal with it.  I can see three obvious ways:
> > 
> >  (1) Treat it the same as hh:mm:59.
> > 
> >  (2) Treat it the same as hh:mm+1:00, rolling over the carry through to the
> >      year if necessary.
> > 
> >  (3) Assign specific time_t values to leap seconds in mktime64().  There's a
> >      table of them here:
> > 
> > 	https://en.wikipedia.org/wiki/Leap_second
> > 
> >      It wouldn't be hard to do within just the kernel, but this would put the
> >      kernel at odds with userspace to the tune of nearly half a minute at the
> >      current time.  It might be sufficient to just fix the libc's in userspace
> >      - but you can bet there's someone somewhere who checks that seconds
> >      doesn't exceed 59.
> > 
> >      The kernel would also need to tell libc whether or not the time value it
> >      gets includes leap seconds.
> > 
> > Any thoughts?
> 
> The kernel supports CLOCK_TAI as a timebase. While I think some operating systems
> use this as the default clock, we don't do that, and I assume we don't want
> to change this.
> 
> ktime_get_clocktai() will return the time in this format, and the timekeeper
> stores the offset between boottime and TAI internally, and updates it whenever
> a leap second happens, so if you set a timer in CLOCK_TAI, it will expire at
> the right moment.
> 
> What I think we don't do at all in the kernel is to keep track of past (or
> even future) leap seconds, so if you need to encode a date in the past,
> the kernel has no idea what the difference between UTC and TAI was at the
> time, and if you encode a time in the future, you don't know if we will
> insert a leap second before you get to that time. I think these are the
> harder questions to solve first if you want to handle the X.509 certificates
> right, before we get to the question of what happens for dates *on* the
> leap second.
> 

My point of view is that we shouldn't do anything in the kernel and
instead handle that with proper TZ files (see leapseconds in
tzdata2015g). You can then handle your own leapseconds epoch and add
future leapseconds without having to update your kernel.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [Ksummit-discuss] Leap second handling

[John Stultz]

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

On Tue, Dec 15, 2015 at 6:15 AM, Alexandre Belloni <
alexandre.belloni@free-electrons.com> wrote:

> On 15/12/2015 at 13:12:03 +0100, Arnd Bergmann wrote :
> > What I think we don't do at all in the kernel is to keep track of past
> (or
> > even future) leap seconds, so if you need to encode a date in the past,
> > the kernel has no idea what the difference between UTC and TAI was at the
> > time, and if you encode a time in the future, you don't know if we will
> > insert a leap second before you get to that time. I think these are the
> > harder questions to solve first if you want to handle the X.509
> certificates
> > right, before we get to the question of what happens for dates *on* the
> > leap second.
> >
>
> My point of view is that we shouldn't do anything in the kernel and
> instead handle that with proper TZ files (see leapseconds in
> tzdata2015g). You can then handle your own leapseconds epoch and add
> future leapseconds without having to update your kernel.
>

So while these approaches are attractive, I think we're kind of stuck with
the current behavior. Posix times don't include leapseconds. So we repeat
the leap-second, and for those that care you can check the adjtimex
timestate to see if the TIME_OOP flag is set to detect leap-seconds in
progress.

So as long as there are leapseconds  (and with the most recent discussion
on abolition not succeeding), we're going to have to keep the existing
behavior.

As for how to treat the certs, you're option #1 "Treat it as hh:mm:59" is
probably the closest to what the kernel does, since it repeats the 59th
second on the leapsecond.

Arnd' suggestion of encoding it into TAI is also something to consider as
it is close to your suggestion, as it basically doesn't have any
leapseconds (just a number of seconds since 1970) but requires you have a
table of leap-seconds to properly translate between TAI time values to UTC
and back. The other problem with TAI is that while the kernel supports it,
not many systems are configured to properly initialize it, so its likely to
match UTC most of the time. But if you're only using TAI internally in your
app, and translating out to UTC as needed, that might not matter.

thanks
-john

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

Re: [Ksummit-discuss] Leap second handling

[David Howells]

John Stultz <john.stultz@linaro.org> wrote:

> As for how to treat the certs, you're option #1 "Treat it as hh:mm:59" is
> probably the closest to what the kernel does, since it repeats the 59th
> second on the leapsecond.

mktime64() appears to treat hh:mm:60 as the equivalent of the 0th second of
the next minute simply by adding the seconds on last with no checking.

I'm okay with implementing #1 or #2 for now (ie. treating as :59 of this
minute or :00 of the next minute) with a comment in the code indicating that
this is what we're doing.

Should I have mktime64() handle it or should I handle it in my X.509 code
though?  I favour the former as it's then a general solution that can be
handled in a single place.  I could put the handling of 24:00:00 being
equivalent of 00:00:00 of the next day there also.

David

Re: [Ksummit-discuss] Leap second handling

[John Stultz]

On Wed, Dec 16, 2015 at 4:32 PM, David Howells <dhowells@redhat.com> wrote:
> John Stultz <john.stultz@linaro.org> wrote:
>
>> As for how to treat the certs, you're option #1 "Treat it as hh:mm:59" is
>> probably the closest to what the kernel does, since it repeats the 59th
>> second on the leapsecond.
>
> mktime64() appears to treat hh:mm:60 as the equivalent of the 0th second of
> the next minute simply by adding the seconds on last with no checking.
>
> I'm okay with implementing #1 or #2 for now (ie. treating as :59 of this
> minute or :00 of the next minute) with a comment in the code indicating that
> this is what we're doing.
>
> Should I have mktime64() handle it or should I handle it in my X.509 code
> though?  I favour the former as it's then a general solution that can be
> handled in a single place.  I could put the handling of 24:00:00 being
> equivalent of 00:00:00 of the next day there also.

I think having it handled in mktime64 sounds reasonable to me. But the
behavior should be very clearly documented there, and ideally match
the kernel's behavior.

Cc'ing in other time folks for their thoughts.

thanks
-john