freebsd security - Jul 2015 - Leap Second

Mark Felder <feld at FreeBSD.org> writes:
> I'm not an expert on the leapsecond operation, but if I understand it
> correctly there are two ways a system can be notified of a leapsecond:
> via a tzdata update or through NTP.
Answering a bit late, but no: in practical terms, only NTP works.
Recording leap seconds in tzdata breaks POSIX and a lot of assumptions
in existing code, not only on the day a leap second occurs but at any
time in history after at least one leap second has occurred.
> 1) FreeBSD server unaware of leapsecond due to no tzdata entry and not
> synced to NTP ends up 1 second off
A server which is not synchronized with a reliable external source will
end up a lot more than one second off regardless of leap seconds,
because it relies solely on onboard RTCs and oscillators which are both
inaccurate and imprecise.  Clock drift will be measured in seconds per
week and vary depending on CPU load, disk I/O, the phase of the moon and
your dog's horoscope.
> 2) FreeBSD server unaware of leapsecond due to no tzdata entry synced to
> leapsecond-aware NTP server successfully handles leapsecond
Correct.
> 3) FreeBSD server unaware of leapsecond due to no tzdata entry acting as
> NTP server doesn't notify clients of leapsecond and they end up 1
second
> off
This assumes that the hypothetical server is not synchronized with a
reliable external source, which is a broken setup to begin with (see 1).

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

On Wed, Jul 1, 2015, at 08:47, Dag-Erling Sm?rgrav
wrote:
> Mark Felder <feld at FreeBSD.org> writes:
> > I'm not an expert on the leapsecond operation, but if I understand
it
> > correctly there are two ways a system can be notified of a leapsecond:
> > via a tzdata update or through NTP.
> 
> Answering a bit late, but no: in practical terms, only NTP works.
Better late than never :-)
> Recording leap seconds in tzdata breaks POSIX and a lot of assumptions
> in existing code, not only on the day a leap second occurs but at any
> time in history after at least one leap second has occurred.
> 
Yeah, I think it's pretty obvious now that doing leapseconds in tzdata
is a bad idea -- worse than leapseconds themselves maybe? :-)
> > 1) FreeBSD server unaware of leapsecond due to no tzdata entry and not
> > synced to NTP ends up 1 second off
> 
> A server which is not synchronized with a reliable external source will
> end up a lot more than one second off regardless of leap seconds
> because it relies solely on onboard RTCs and oscillators which are both
> inaccurate and imprecise.  Clock drift will be measured in seconds per
> week and vary depending on CPU load, disk I/O, the phase of the moon and
> your dog's horoscope.
> 
I was ignoring that bit, but it's worth pointing out to the readers. I
should have worded it "...will be one *more* second off" :-)