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:	Wed, 07 Jan 2009 10:36:45 -0700 (MST)
From:	"M. Warner Losh" <imp@...imp.com>
To:	linasvepstas@...il.com
Cc:	mayer@....isc.org, david@...g.hm, hancockr@...w.ca,
	kyle@...fetthome.net, slashdot@...eshallam.info,
	goodgerster@...il.com, davidn@...idnewall.com,
	linux-kernel@...r.kernel.org, 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: <3ae3aa420901062052h75fcab11n8ce45c41ac0e4cd2@...l.gmail.com>
            "Linas Vepstas" <linasvepstas@...il.com> writes:
: However, during the discussion, the idea came out that
: maybe keeping UTC time in the kernel is just plain stupid.
: So there's this idea floating around that maybe the kernel
: should keep TAI time instead. The hope is that this will
: reduce the complexity in the kernel, and push it out to
: user space, "where it belongs" (to repeat a well-worn
: mantra).

I agree that this is where it belongs, but it is hard to do that in a
POSIX compliant way.  It also becomes hard to timestamp things in
filesystems using UTC rather than TAI.  There are other protocols that
deal with UTC times as well.

: However, *if* we were to kick UTC out of the kernel,
: and push it to user-land, then, of course, there's a
: different problem: how does the kernel know what the
: correct TAI time is?  As your reply makes abundantly
: clear, NTP is not a good source for TAI information.

Agreed.  That's the whole crux of the 'multiple time scales suck'
threads that I've talked about in other forums.  You have to know this
information before you start, have to deal with 'dusty system' problem
for systems that have been off for 6 months or not upgraded.  You also
have to cope with learning after the fact that your initial guess was
wrong.

I've had many systems that would get this information from GPS and
stall the rest of the system until this data came in.  I did this
mostly because there were big issues with the software down stream if
you changed the delta between your putative UTC and TAI after the
fact.

: The comments which you labelled as "non-sense" were
: a mis-understanding of  a discussion of a particular issue
: that would arise if the kernel were to keep TAI -- if it did,
: then user-space systems would need to have a reliable
: source for leap-seconds. Since NTP does not
: provide this, there was discussion about how that
: could be worked-around. This then lead to the comment
: that, "gee, wouldn't the right long-term solution be that
: NTP provide TAI info?"

I've wanted this for a long time...

: Clearly, it would be a lot of work to get the kernel to keep
: TAI instead of UTC, so this is not, at this time, a "serious
: proposal".  But if it were possible, and all the various
: little issues that result were solvable, then it does seem
: like a better long-term solution.

Yes.  The kernel would need to be able to return both UTC and TAI
times to the kernel as well, since there are requirements for NFS to
return timestamps in UTC, not in TAI.  Many file systems specify UTC
time, or have traditionally been implemented that way.

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/