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]
Message-ID: <3ae3aa420901062052h75fcab11n8ce45c41ac0e4cd2@mail.gmail.com>
Date:	Tue, 6 Jan 2009 22:52:20 -0600
From:	"Linas Vepstas" <linasvepstas@...il.com>
To:	mayer@....isc.org
Cc:	david@...g.hm, "Robert Hancock" <hancockr@...w.ca>,
	"Ben Goodger" <goodgerster@...il.com>,
	"Kyle Moffett" <kyle@...fetthome.net>,
	MentalMooMan <slashdot@...eshallam.info>,
	"David Newall" <davidn@...idnewall.com>,
	linux-kernel@...r.kernel.org, ntpwg@...ts.ntp.isc.org,
	"Travis Crump" <pretzalz@...hhouse.org>, burdell@...ntheinter.net,
	"Nick Andrew" <nick@...k-andrew.net>,
	"Jeffrey J. Kosowsky" <jeff@...owsky.org>
Subject: Re: [ntpwg] Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009

2009/1/6 Danny Mayer <mayer@....isc.org>:
Hi,

> I don't know what this discussion is really about and why this was sent
>  to the working group in the middle of the discussion, but there is no
> need for NTP to provide TAI information since NTP only uses UTC. Leap
> Seconds are automatically signaled  and incorporated when they become
> due. If you don't have NTP running for some reason when a leap second is
> signaled it doesn't matter since your server source will already have
> incorporated the leap second so the NTP packet includes the timestamps
> that include the leap second adjustment.
>
> Operating Systems use UTC and not TAI by universal agreement and the
> ones that don't are extremely rare.
>
> Why don't you tell us what the real problem is instead of telling us
> that you need TAI offset information?

Currently, the Linux kernel keeps time in UTC. This means
that it must take special actions to tick twice when a leap
second comes by.  Due to a (stupid) bug, some fraction
of linux systems crashed; this includes everything from
laptops to servers, to DVR's,  to cell phones and cell
phone towers. There's now a fix for this.

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).

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.

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?"

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.

--linas

p.s. the opinions above are not my own; I'm just
summarizing the points made by the most vocal
posters to this list.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ