linux-kernel - Re: [ntpwg] Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Jan 2009 10:07:12 -0700 (MST)
From:	"M. Warner Losh" <imp@...imp.com>
To:	pavel@...e.cz
Cc:	linasvepstas@...il.com, david@...g.hm, goodgerster@...il.com,
	kyle@...fetthome.net, slashdot@...eshallam.info,
	davidn@...idnewall.com, linux-kernel@...r.kernel.org,
	hancockr@...w.ca, ntpwg@...ts.ntp.isc.org, pretzalz@...hhouse.org,
	burdell@...ntheinter.net, nick@...k-andrew.net, jeff@...owsky.org
Subject: Re: [ntpwg] Bug: Status/Summary of slashdot leap-second crash on
 new years 2008-2009

In message: <20090112161115.GA1474@....cz>
            Pavel Machek <pavel@...e.cz> writes:
: On Mon 2009-01-05 11:42:35, Linas Vepstas wrote:
: > 2009/1/5  <david@...g.hm>:
: > > On Mon, 5 Jan 2009, Linas Vepstas wrote:
: > >
: > >>> Arguably the kernel's responsibility should be to keep track of the
: > >>> most fundamental representation of time possible for a machine (that's
: > >>> probably TAI) and it is a userspace responsibility to map from that
: > >>> value to other time standards including UTC,
: > >>
: > >> Yes, this really does seem like the right solution.
: > >>
: > >>> using control files
: > >>> which are updated as leap seconds are declared.
: > >>
: > >> Lets be clear on what "control files" means.  This does
: > >> *NOT* mean some config file shipped by some distro
: > >> for some package. That would be a horrid solution.
: > >> People don't install updates, patches, etc.  Distros
: > >> ship them late, or never, if the distro is old enough.
: > >>
: > >> A more appropriate solution would be to have
: > >> either the kernel or ntpd track the leap seconds
: > >> automatically.  First, the ntp protocol already provides
: > >> the needed notification of a leap second to anyone
: > >> who cares about it (i.e. there is no point in getting a
: > >> Linux distro involved in this -- a distribution mechanism
: > >> already exists, and works *better* than having a distro
: > >> do it).
: > >
: > > I disagree with this. NTP will only know about leap seconds if it was
: > > running and connected to a server that advertised the leap seconds during
: > > that month.
: > >
: > > for example, if you installed a new server today, how would it ever know
: > > that there was a leap second a couple of days ago?
: > 
: > OK, good point.  Unless your distro was less
: > than a few days old (unlikely), you are faced with the
: > same problem.  Sure, eventually, the distro will publish
: > an update (which will add to the existing list of 36 leap
: > seconds -- which is needed in any case, since no one
: > has a server that's been up since 1958),  but this is
: > unlikely to happen during this install window.
: > 
: > The long term solution would be write an RFC to extend
: > NTP to also provide TAI information -- e.g. to add a
: > message that indicates the current leap-second offset
: > between UTC and TAI.
: 
: Offset is not enough; you'd have to provide list of all previous leap
: seconds with 'when it happened' timestamps.

Well, today you can ftp the leapseconds.txt file from NIST.  Of
course, that assumes your machine is on the network, and not a dumb
slave of a smart head-end that's off the net...

Warner
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/